Find the limits before you build something that needs to cross them.
host-capabilities.txt
I'm building <one sentence> with <stack>, hosted on <host>.
Before I write more code, tell me what this host realistically lets me do.
For each, say yes, no, or "check this", and how I'd check:
- Which runtime versions are available, and can I choose?
- Can I run scheduled jobs? How often, at minimum?
- Can I run a long-lived process: a worker, a websocket server, a queue?
- Is there shell access, or only a file manager and FTP?
- Can the server make outbound HTTPS calls to third-party APIs?
- Memory limit, request timeout, and upload size limit.
- Which databases are included?
Then list anything in my plan that this host can't do, and the cheapest
way round each one.
Ask before you build. The most expensive discovery in a small project is that the host kills any request longer than 30 seconds, found after the feature that needs two minutes is finished.
A padlock is step one. Redirects, mixed content and cookies are the rest.
https-on-my-host.txt
My site runs <stack> on <host>. I need HTTPS set up properly.
Walk me through it for this specific host:
- Getting and renewing the certificate. Is it automatic here? What do I
click or run?
- Redirecting every http:// request to https://, once, without a loop.
- Finding mixed content: anything still loading over http.
- Marking cookies Secure so they're never sent unencrypted.
- Whether to turn on HSTS now, and why I might want to wait a week.
Tell me how to test each step, and what breaks if I get the redirect wrong.
Leave HSTS until everything works over HTTPS for a few days. It tells browsers to refuse plain HTTP for months, so a mistake made with it switched on is hard to undo.
I need <describe the task> to run <how often>. My project uses <stack>
and runs on <host>.
Give me the exact setup for this host:
- Where scheduled jobs are configured here: a control panel page, a
crontab, or a platform config file.
- The exact line or setting, with full paths to the runtime and script.
Scheduled jobs often run with a different path and user than my site.
- How to capture the output somewhere I can read it.
- How to stop two runs overlapping if one runs long.
- How I'll know it stopped running, not just that it failed.
Then give me a one-line way to run it by hand, so I can test it first.
The classic failure is a job that works when you run it and does nothing on the schedule. It's almost always a relative path or a runtime the scheduler can't find. Full paths everywhere.
My app is <stack> on <host>. Something is going wrong and I need the logs.
Tell me, for this host:
- Where the web server's access and error logs are, and how I reach them:
file manager, shell, or the host's dashboard.
- Where my application's own errors end up, and whether they're being
written at all or silently discarded.
- How long logs are kept before they're deleted.
- How to watch new lines arrive while I reproduce the problem.
Then show me how to make my app log errors with enough detail to debug,
without ever showing that detail to visitors.
Set this up before you need it. The worst time to learn where your host keeps its error log is while the site is down.
Daily backups" on a pricing page is not a restore plan.
host-backups.txt
I run <stack> on <host>. I'm assuming the host backs things up, and I
want to know whether that assumption is safe.
Find out and tell me:
- What exactly is backed up: files, databases, email, configuration?
- How often, how many copies are kept, and for how long?
- Are the backups stored somewhere other than the server they back up?
- How do I restore, and is restoring free or a paid support request?
- Can I restore one file or one table, or only everything at once?
Then list what isn't covered, and give me the smallest backup of my own
that covers the gap.
Many hosts restore only the whole account, overwriting everything since. That's fine for a disaster and useless when you've deleted one table by accident.
A migration in order, with a way back at every step.
move-host.txt
I'm moving a site built with <stack> off <host> to <new host>.
Give me a migration plan I can follow in order:
1. What to inventory first: files, databases, scheduled jobs, email,
environment settings, DNS records.
2. Setting up and testing the new host before any traffic goes there.
How do I preview it on its real domain without switching DNS?
3. Freezing changes so nothing is written to the old host mid-move.
4. The DNS switch, with the TTL lowered a day before.
5. What to check in the first hour after switching.
6. How long to keep the old host running, and how to roll back.
Flag anything that commonly gets forgotten.
Email is the thing that gets forgotten. If the old host handled your domain's mailboxes, switching DNS can silently move them somewhere nothing is listening.
The records to add, where to add them, and how to check.
domain-on-my-host.txt
My site is <stack> on <host>. My domain is registered with <registrar>.
Tell me exactly what to set up:
- Which DNS records to add, where, and what goes in each field.
Does the name field want "@", "www", or the full domain here?
- Whether to point the domain at the host's nameservers or add records
at the registrar, and which is simpler for me.
- Making both example.com and www.example.com work, with one redirecting
to the other.
- A command I can run to see what the world sees, without waiting.
If email is involved, tell me which records I must not break.
If it hasn't worked after an hour, the record is wrong. Waiting longer won't fix a typo.
Some hosts have no environment variables. Here's where keys go instead.
secrets-on-my-host.txt
My app uses <stack> on <host> and needs API keys and database passwords.
Tell me the right way to store secrets on this host:
- Does it support environment variables for my app? If so, where do I
set them?
- If not, where can I put a config file so it's outside the web root and
can never be downloaded by URL?
- File permissions for that file.
- How my code should read it, with a clear error if it's missing.
- How to check nobody can fetch it from a browser.
Then: what should I do if a key has already been in a file inside the
web root?
Assume a key that was ever downloadable has been downloaded. Rotate it, then fix where it lives.
Slow, then fine, then slow again usually means a limit.
host-limits.txt
My site (<stack> on <host>) gets slow, returns errors, or goes down under
load, and then recovers on its own.
Help me find out whether I'm hitting a host limit:
- Which limits this host enforces per account: CPU, memory, processes,
connections, file count, bandwidth.
- Where the host shows my usage against those limits.
- What my app might be doing that spikes each one.
- What visitors see when each limit is hit.
Then rank the fixes: things I can change in my code, settings I can
change on this host, and the point where I should upgrade the plan.
Shared hosting limits are often counted per account, not per site. Another project on the same account can be the thing slowing this one down.
I deploy a <stack> project to <host>. Here's my file layout:
<paste the file tree>
Check what a stranger could reach:
- Which files in the web root can be downloaded that shouldn't be:
configuration, .env files, backups, .git folders, logs, SQL dumps.
- Whether directory listings are switched on.
- Whether error pages leak paths or stack traces.
- File and folder permissions that are wider than they need to be.
- Anything left over from development: test scripts, admin tools,
phpinfo pages, sample files.
For each, give me the fix for this host and a URL I can visit to prove
it's closed.
Try fetching /.git/config and /.env on your own site. Automated scanners request both within hours of a site going live.
I'm building <one sentence> with <stack> on <host>. Things that are
starting to hurt: <list what's annoying you>.
Tell me honestly whether I've outgrown this host, or whether the problem
is my code or configuration.
If it is the host:
- What specifically would a different host fix?
- What's the smallest step up that fixes it: a bigger plan here, a VPS,
or a managed platform?
- What would I have to change in my project to move?
- What new work would I be taking on, like server updates or backups?
If it isn't, say so and tell me what to fix instead.
Moving host is rarely the fix for slowness. A missing database index follows you to the faster server.
No half-uploaded files, no error page while it copies.
safe-deploy.txt
I deploy <stack> to <host> by <how you deploy now: FTP, git pull, a
button>. During a deploy, visitors sometimes see errors.
Design a safer deploy for this host:
- Upload to a separate folder first, then switch over in one step, so no
one ever sees half the new files and half the old.
- Database changes that are safe to run while the old code is still live.
- A cache-busting approach so browsers don't mix old CSS with new HTML.
- A rollback that takes one command or one click.
Keep it to what this host can actually do. I don't want tooling I can't
run here.
Uploading files one by one over live code is the usual cause of "it errored for a minute during the deploy". Switching a folder or a symlink makes the change instant.
Compression and caching headers, set up for this server.
caching-on-my-host.txt
My site is <stack> on <host>. I want pages to load faster without
changing hosts.
Set up, for this host's web server:
- Compression for HTML, CSS, JavaScript and SVG.
- Long cache lifetimes for files whose names change when their content
does, and no caching for HTML.
- Whether this host has a built-in cache or CDN I should switch on.
- Anything in my app that stops caching from working, like cookies set
on every response.
Give me the exact configuration for this server, and how to check the
headers each response actually sends.
Check the response headers, not the page speed score. A single wrong Cache-Control header can undo everything else you set.
I work on a <stack> project hosted on <host>. Right now I change files by
<how you do it now>.
Help me set up something safer that this host supports:
- SSH or SFTP with a key instead of a password, if available.
- Deploying from version control rather than editing live files.
- A way to see what changed on the server, and undo it.
- Separate credentials for anything automated, so I can revoke one
without locking myself out.
If this host only offers FTP, tell me the least risky way to work with it.
Editing live files directly means the server is the only copy of your latest work. Put it under version control before you change anything else.