PlatformHosting
App hosting, without the infrastructure.
Antideploy reads your project, builds it into a container, runs it behind HTTPS and keeps an eye on it. No Dockerfile, no YAML, no cloud console. Your coding agent does the setup and hands you a live link.
- No DockerfileYour code is read and built into a container for you
- HTTPS from the first deployA name.antideploy.app address with its certificate
- SingaporeApp and database in one region, close to India and Southeast Asia
- Sleeps when idleA sleeping app costs nothing and wakes on the next visit
01How it works
Read the project, then run it.
You do not describe your app to Antideploy. It works it out from your files, tells you what it found, and only then builds.
Your agent deploys. You get a link.
Antideploy works out the language, framework, build and start commands, port and whether your app needs a database straight from your files, and every conclusion names the file it came from. Then it builds a container, releases it, checks that it is healthy and returns the live address.
- The analysis is deterministic: the same code always gets the same answer
- Things that will not work once live, such as saving uploads to disk, are flagged before anything is built
- It reads which environment variables your code expects, never what is in them
> Deploy this project with Antideploy
Read the project Node 22 · Next.js · Postgres · port 3000
Build container built, migrations ran
Release health check passed
Live at https://verdant.antideploy.appYour own Dockerfile, if you have one.
If there is a Dockerfile at the root of your project, it is used. Without one, buildpacks turn your code into a container. Either way you write no YAML and open no cloud console.
- A custom Dockerfile builds from the first deploy for accounts signed in with GitHub or Google, and on any paid plan
- An account made with only an email address waits until it is 7 days old
- While an account waits, a project Antideploy recognises is built without its Dockerfile, and the deploy says so
Runtime Node 22 package.json:3
Framework Next.js 15 package.json:10
Build next build package.json:6
Start next start package.json:7
Database Postgres schema.prisma:2
Variables DATABASE_URL, STRIPE_SECRET_KEY02What you get
A server that stays a server.
Each app is one long-running process with a real address, a database beside it and the services it needs, not a function that disappears after every request.
-
HTTPS and an address, from the first deploy. Every app gets its own https address the moment it is live, with the certificate issued for you. Rename it whenever you like, and the old address stops working at once. Paid plans can use their own domain.
-
Servers behave like servers. Because each app is one process, servers that keep state in memory or hold WebSocket connections open behave as they would on your own machine. Antideploy sets no time limit of its own on a connection.
-
A database beside it. If your code needs Postgres, one is created in the same region and wired in as
DATABASE_URL. See the database. -
Watched, day and night. Health is checked every few minutes, and you get an email when an app goes down and another when it is back. See logs and monitoring.
-
A security check after every deploy. Right after a deploy goes live, it looks for the mistakes that leak data, such as keys shipped to the browser. Free, every time. See security checks.
-
Asleep when idle, awake on demand. An app nobody is using goes to sleep, and the next visit wakes it. In our measurements that first request took 2.9 to 13.9 seconds depending on the stack. A sleeping app costs you nothing.
03Limits by plan
Pick by how many apps you keep online.
- 1
- live app on Free
- 3
- live apps on Go
- 9
- live apps on Pro
- 20
- live apps on Scale
A live app is one with a server and a working address. Static sites never count, drafts and apps whose deploys all failed do not count, and failed deploys are free. See every limit on the pricing page.
04Reference
What every app runs on.
The same on every plan, fixed today.
| Setting | Value |
|---|---|
| Compute | 1 shared vCPU and 1 GB of memory per app |
| Instances | One per app. There is no pool behind a load balancer. |
| Region | Singapore, with the database beside the app. Choosing a region is not offered today. |
| Address | name.antideploy.app, 2 to 40 characters of lowercase letters, digits and hyphens. Rename it whenever you like. |
| Idle behaviour | Sleeps when nobody is using it and wakes on the next visit. The first request takes 2.9 to 13.9 seconds, depending on the stack. |
| Health | Checked about every five minutes, with an email when an app goes down and when it recovers. |
| Limits we do not set | Storage, bandwidth and build minutes are not metered or capped today. |
05Before you commit
Here's where it stops.
A platform that only tells you what it is good at is one you find the edges of in production. These are hosting's, and we flag them when we read your code, before you deploy.
-
One instance per app
Not a pool behind a load balancer. If you need horizontal scale today, use something else.
-
One region
Everything runs in Singapore. Choosing a region is not offered today.
-
No always-on workers
Apps sleep when idle, so a background loop will not stay alive. Use a cron job or a webhook instead.
-
No staging or previews
One deployed version per project. There are no per-branch URLs and no preview databases.
-
The disk forgets
Anything written to local disk is gone on the next deploy. Apps that speak S3 get a bucket instead.
06Questions
Hosting questions, answered.
Anything else? Write to us and a person answers.
support@antideploy.comWhat can I host?
Websites and apps in Node, Python, Go, Ruby or Java: Next.js, Vite, Express, FastAPI, Flask, Django, Rails, Streamlit and plain static sites among them. If there is a Dockerfile at the root of your project, it is used.
Do I need to write a Dockerfile?
No. Antideploy reads your project and builds it for you. If you do have a Dockerfile at the root, it is used, subject to the account rules in the Dockerfile section above.
Where do my apps run?
In one region, Singapore, close to users in India and Southeast Asia, with the database beside the app. Choosing a region is not offered today.
Do apps sleep?
Yes, on every plan. An app that nobody is using goes to sleep and the next visit wakes it. In our measurements the first request took 2.9 to 13.9 seconds depending on the stack. A sleeping app costs you nothing.
How much CPU and memory does an app get?
One shared vCPU and 1 GB of memory per app, on every plan. These are fixed today.
Can I run more than one copy of my app?
No. Each app is one instance. If you need horizontal scale today, use something else.
Can I run a background worker or a queue consumer?
Not today. Only the web process runs, and apps sleep when idle, so a loop inside it will not stay alive. Use a cron job to call a path on a schedule, or a webhook.
What counts as a live app?
An app with a server and a working address, which means at least one of its deploys went live. Drafts, apps whose deploys all failed, and static sites do not count toward your limit.
What can I not host?
Crypto miners, remote desktops such as VNC and RDP, and remote shells or tunnels are refused when the project is analysed, and so are pages built to steal logins. The deploy fails saying why, and retrying will not change that.
Are bandwidth, storage or build minutes capped?
No. None of the three is metered today, so nothing is measured, billed or cut off.
+The rest of the platform
Everything else your app can use.
Every service is created by your coding agent, wired into your app, and included in the plans. See the whole platform.
- Static sites
- Deployments
- Database
- Authentication
- File storage
- AI models
- Cron jobs
- Custom domains
- Environment variables
- Logs and monitoring
- Security checks
- Console
- Agent API
Facts on this page were checked against the live platform on 5 October 2026.
Put your app online. Just ask your agent.
Paste one sentence into your coding agent, click Approve once, and get a live link. No card, no trial clock.