What '10 Deploys a Day' Really Means: The 5-per-12-Hours Rule, Failed Builds, and the $1 Way Around It

The free tier says "10 deploys a day". The rule that actually runs is "5 deploys per rolling 12-hour window", and the difference matters on the afternoon you are debugging a Dockerfile. This post explains the rule as the code applies it: what counts as a deploy, what does not, when the counter resets, who is exempt, and the cheapest ways to never notice it. It exists because the second most common support question after "why did my container sleep" is "why can't I deploy".

The rule, precisely

• A free account gets 5 deploys per rolling 12-hour window. Two windows a day is where "10 a day" comes from, but nothing resets at midnight.
• The window is measured two ways, and whichever comes first reopens it: 12 hours after the fifth deploy (a cooldown from the moment the limit was hit), or 12 hours after the last deploy if you never reached five (an inactivity reset).
• A deploy is counted when it is attempted. Failed builds count. A Dockerfile that fails at npm ci five times in an hour uses the window.
• A restart counts. Restart stops the container and redeploys it, and the counter is consumed the moment you trigger it. Starting a container that never finished its first deploy counts for the same reason: that start is the deploy.
• When you hit the limit, the dashboard says so and you get one email per window. Nothing is deleted or stopped; the running containers keep running.

What does not count

• The sample apps in the first-deploy wizard. Deploying the Flask, Node.js or Nginx sample is a prebuilt image and is excluded from the counter, so trying the platform never spends your deploys. They stop by themselves after an hour.
• GPU containers, which are on their own subscription and their own rules.
• Waking a sleeping container, from the wake page or by pressing Start on a container that has deployed before: it scales the existing task back up. No build, no deploy. Stopping a container is free too.
• Editing environment variables restarts the container with the same image; it is not a new build.

Who is exempt

The cap applies to free accounts. It lifts, for as long as the condition holds, when any of these is true:

• You have an Always-On container ($12/month per container). Unlimited deploys across the account, not only on that container.
• You have an active Sprint Pack, the $1 pack that gives a container 24 hours of Always-On behaviour. While its 24 hours run, deploys are unlimited. That makes a dollar the honest answer to "I have a long debugging session ahead".
• You are on a paid plan, or you hold GPU credit balance.

Why there is a cap at all

A build is the one part of the free tier that a script can spend without limit: every deploy builds an image and starts a container, and a loop can do that all day. Five per twelve hours is more than a person debugging by hand needs, and it is what keeps the free tier available for the people it is meant for. Paid plans and Sprint Packs lift it because they are not the abuse case.

Spending fewer deploys

1. Build the image on your machine first. docker build -t app . && docker run --rm -p 8080:8080 -e PORT=8080 app catches the missing file, the wrong port and the failing install in seconds, at no cost to the window. Almost every deploy that fails on the platform would have failed locally.
2. Batch changes. Three small pushes are three deploys. One push with three commits is one.
3. Use the wizard samples to learn the platform. They are free of charge to the counter, so click around on them, not on your own build.
4. Read the build log before retrying. The failure reason is in the log; retrying the same push produces the same log and spends a deploy.
5. If it is a real debugging day, buy a Sprint Pack. $1, 24 hours, unlimited deploys, and the container does not sleep either.

Reading the counter

The dashboard shows deploys remaining in the current window next to the deploy button. When it reads zero, the message tells you when the window reopens: 12 hours after the fifth deploy. If you deployed five times between 09:00 and 10:00, you are back at 22:00, not at midnight and not "tomorrow". If you deployed twice at 09:00 and then nothing, the two are forgotten by 21:00 and you have five again.

What happens to the running container

Nothing. The cap is on new deploys, not on service. A container you deployed earlier keeps serving, sleeps after 15 minutes without traffic as usual, and wakes on the next visit. The 100-hour monthly budget is separate: deploys do not consume hours, and hours do not consume deploys.

A debugging afternoon, as the counter sees it

The same afternoon with a local docker build and docker run before each push is two deploys, not five: the missing file, the missing variable and the wrong port all show up on your laptop. That is the whole argument for testing the image locally, and it is why the cap rarely touches people who do.