You
State the outcome
“Analyze what this app needs, then ship it to dev.”
You approve production changes and provide secret values when the application requires them.
Full-stack app hosting for coding agents
One prompt.
The whole cloud
behind your app.
Your coding agent already understands the repository. Anyhost gives it one CLI and skill to deploy the app, attach the services it needs, inspect the result, and move from isolated dev to confirmed production.
GitHub repository required · start in dev · production changes require explicit confirmation
›
analyze what this app needs, then ship it to dev
one instructionone operating envelope
RUNApp runtimepinned commit
SQLPostgresmanaged data
KVRediscache + queues
OBJStorageproject scoped
KEYSecretsmasked values
DNSDomainsHTTPS state
MAILEmailruntime delivery
AIModel APIbudgeted access
OBSLogs + healthevidence returned
dev isolated
verify health + logs
prod confirmation gated
One service, not one feature
App hosting is the runtime—and the cloud around it.
A deploy button solves the first five minutes. Anyhost packages the ongoing cloud work your application creates into one project your coding agent can actually operate.
LayerWhat your app getsWhat your agent can verify
Deliver
App runtimeDomains + HTTPSEnvironment secrets
Pinned commit, public URL, certificate state
Data
PostgresRedisObject storage
Resource status and generated runtime variables
Connect
EmailModel APICustom service needs
Environment binding, budget and delivery state
Operate
Deploy historyLogsHealth checks
Terminal status, failure reason and live evidence
Only provision what the repository actually needs. Services stay scoped to the project and target environment.
From demo to production
Dev is a workspace. Prod is a decision.
Each environment keeps its own runtime, resources and configuration. Your agent can inspect production state, but creating or changing production infrastructure requires an explicit confirmation at the CLI boundary.
isolated configuration
environment-scoped services
production confirmation
devlive
Build the real stack
runtime · postgres · storage · secrets
evidence gate
health 200 · logs clean · URL verified
prodconfirmation required
Promote deliberately
no silent production mutation
The deliverable
Not a confetti screen. A deployment receipt.
Your agent gets machine-readable evidence it can use in the next debugging conversation: what commit shipped, which services are ready, where the app is running, and whether health passed.
source commit
resource state
public URL
health evidence
- repository
- acme/customer-portal
- source_commit
- 8f21c40
- runtime
- ready
- postgres
- available
- storage
- available
- public_url
- https://portal-dev.anyhostcloud.com
- health
- 200 · verified
- production
- not requested
Anyhost application receiptdev
When the fit is strongest
Use a static host for a static page. Use Anyhost when the app becomes a system.
A frontend with no backend state
If all you need is a static marketing page, a simpler host may be enough.
An app with services and environments
Anyhost becomes useful when the repository needs a backend, data, files, secrets, email, models, domains or production controls.
A coding agent doing the shipping
The CLI and installed skill let the agent already working in your code operate the matching cloud services without raw provider access.
Start in this repository
Give your coding agent the cloud brief.
This prompt asks for an inspection before provisioning, a real dev deployment, and evidence before any production decision.
Paste into Claude Code, Codex, Cursor, or another coding agent
Fetch https://anyhost.app/agent-setup/prompt.md and follow it to set up Anyhost in this repository. Then analyze what this existing application needs and ship it to the Anyhost dev environment. Inspect the repository before proposing infrastructure: identify its build and start commands, health behavior, required secrets, and whether it actually needs Postgres, Redis, object storage, Email, or Model API access. Make any required application change explicit. Provision only the services the repository needs, configure the dev environment, deploy the pushed commit, verify the public URL and supported health path, inspect the runtime logs, and return a deployment receipt with service status. Ask for my explicit confirmation before creating or changing anything in production.
Straight answers
Know what the “one prompt” does—and does not do.
Does Anyhost analyze or rewrite my application?
No. The coding agent you are already using inspects and changes the repository. Anyhost provides that agent with a scoped CLI and skill for deployments, environments and managed cloud services.
Does my repository need a Dockerfile?
Build requirements depend on the application and the supported Anyhost deployment path. Your coding agent inspects the repository and makes any required application or packaging change explicit before deployment; Anyhost does not silently invent application behavior.
Can one project use Postgres, Redis and object storage together?
Yes. Managed resources are project- and environment-scoped. When a resource is ready, supported generated variables are made available to new deployments without putting raw provider credentials in the repository.
Is this an alternative to Heroku, Railway or Render?
It can serve the same application-hosting job, but the interface is different: your coding agent operates the runtime and matching managed services through the Anyhost skill and CLI. The useful distinction is not another deploy button; it is one agent-operated project boundary for the wider application stack.
Will the prompt change production automatically?
No. It starts in dev. Production deployments and production resource changes require explicit confirmation at the CLI boundary.
Your agent has the code. Give it the cloud.
One project for the runtime, services, environments and evidence your application needs after the demo.