Functions time out. Background work has nowhere to live. The database, the cache, the object store and the email sender each come from somewhere else, with their own dashboard and their own bill. AnyHost runs your backend as a container and brings the rest with it.
Free tier, no card. Postgres, Redis, storage, email and domains included · pricing
Serverless is an excellent fit for work that starts when a request arrives and finishes before it leaves. Most apps eventually need the other kind: a job that runs for four minutes, a worker that drains a queue, a connection that stays open, a nightly task. Fitting that into functions is where the workarounds start.
Long work gets split, queued elsewhere, or moved to a second provider. Connection pooling needs a proxy. State needs somewhere else to live.
Same app, ordinary server code. Background jobs, pooled connections and long requests are just code, not an architecture decision.
Vercel has been closing this gap — Services and Dockerfile support move it toward long-running workloads. Judge it on where each product's centre of gravity is: theirs is the frontend and the edge, ours is the backend and the stateful services around it.
Two of these rows go to Vercel outright, and if either one is central to how you work, stay where you are.
| Capability | Vercel | AnyHost |
|---|---|---|
| Frontend hosting and edge CDN | Best in class | Yesglobal CDN, managed HTTPS, health-aware public routes |
| Per-pull-request preview deployments | Best in class | Notwo fixed environments — dev and prod — not one per branch |
| Framework-specific build tooling | DeepNext.js is theirs | Genericbuilds from your Dockerfile or detected stack |
| Long-running processes and workers | Servicesnewer addition; functions are the default path | Container runtimethe default and only model |
| Managed Postgres | Marketplacethird-party, separately billed | First-partyDATABASE_URL injected per environment |
| Managed cache / Redis | Marketplace | First-partyencrypted, per-environment, key-prefix injected |
| Object storage | Blob | S3-compatibleprivate by default, optional public delivery path |
| Transactional email | No | Yescustom sending domain, delivery events, suppression |
| Custom domains and certificates | Yes | Yesapex support, DNS validation, HTTPS smoke check after cutover |
| Driven by your coding agent | MCP + plugin | CLI + installed skillmachine-readable results, production confirmation at the mutation boundary |
Vercel capabilities as documented publicly at the time of writing. AnyHost rows correspond one-to-one with our services page.
Builds from an immutable commit, structured failure reasons instead of a wall of log, health checks tied to the deployed URL, and redeploy to a known-good commit when a change goes wrong.
Dev and prod get separate URLs, separate secret sets and separate resources. Values are masked by default, and production mutations require explicit confirmation.
Postgres, Redis and object storage, each scoped to one project environment, with connection variables generated and injected rather than pasted between dashboards.
Global CDN, managed HTTPS, custom domains with DNS validation and apex support, and a public HTTPS smoke check after the cutover moves traffic.
Deployment evidence, runtime logs, health responses, and usage attributed down to project, environment and resource — readable by you or by your coding agent through the CLI.
No signup needed to start. The prompt points your agent at our bootstrap instructions; it installs the CLI and a project-local skill package, then works inside your repository. Your Vercel project keeps serving traffic until you decide to switch DNS.
Fetch https://anyhost.app/agent-setup/prompt.md and follow it to set up Anyhost in this repository. Then move this app off Vercel onto Anyhost: containerize it, provision Postgres and any cache or storage it needs, port the environment variables, convert serverless functions into normal backend routes, and get it healthy on the dev environment. Ask me to confirm before anything touches production, and leave the domain on Vercel until I say to cut over.
Your agent will ask you before it changes anything in production — that confirmation boundary is enforced by the CLI, not just by the prompt.
Yes — it builds and runs as a normal Node application in a container. What you give up is the framework-specific tuning Vercel does for its own framework, and per-branch preview URLs. What you gain is that the same container also runs your background jobs and holds pooled database connections.
That's a common and sensible split. Keep the frontend where its build tooling is happiest, run the API, workers and stateful services here, and point one at the other. Nothing requires an all-or-nothing move.
No. Every project gets exactly two environments — dev and prod — with separate URLs, secrets and resources. If per-branch previews are core to how your team reviews work, that's a real gap and you should weigh it.
First-party managed Postgres, provisioned per environment, with DATABASE_URL injected into the runtime and time-limited direct-access profiles for humans. Standard Postgres — take the connection string and leave whenever you want.
Free covers one development runtime with managed database, storage, CDN and email inside fixed limits, with no invoice. Pro is $20 per workspace per month and includes $20 of monthly infrastructure credit plus production environments, with pay-as-you-go beyond that. Full rates are on the pricing page, itemized per resource.
Move one app over and leave your Vercel project serving traffic until you're satisfied. Nothing about this is one-way.
Get the migration prompt