Private Docker Registry Hosting Without Docker Hub Rate Limits
If you want private Docker registry hosting without paying for it separately or hitting Docker Hub's pull limits, JustRunMy.App gives every account its own registry on its own subdomain, with generated credentials and no pull quota. You docker login, docker build -t <your-registry>/<repo>:<tag> ., docker push, and the platform runs that image — the registry and the runtime are the same system, so there's no third-party account in the middle and nothing to rate-limit. Images are private by default; there's no public listing to opt out of.
What Docker Hub's limits actually are
Worth being precise, because the numbers changed and a lot of blog posts still quote old ones. Per Docker's own documentation, pulls are capped in a rolling 6-hour window:
| Account | Pull limit |
|---|---|
| Unauthenticated | 100 per IPv4 address or IPv6 /64 subnet, per 6 hours |
| Personal (free, authenticated) | 200 per 6 hours |
| Pro, Team, Business | Unlimited |
Source: Docker Hub usage and pull limits.
Those are shared-IP numbers, which is what makes them bite. A CI runner on a cloud provider shares an egress IP with everyone else on that provider, so the unauthenticated budget can be gone before your pipeline starts — which is why GitLab warned its users ahead of the change and recommended authenticating or mirroring (GitLab) and Red Hat published mitigation guidance for the same problem (Red Hat).
The usual fixes are to authenticate every pull, mirror upstream images, or pay. All three are fine. They're also all overhead you only carry because your registry and your runtime are different companies.
Your own registry, on your own subdomain
Open Docker Push on the Advanced tab of Create new application and you get three commands.
docker login -u <user> -p <password> <your-id>.justrunmy.app
docker build -t <your-id>.justrunmy.app/<repo>:v1 .
docker push <your-id>.justrunmy.app/<repo>:v1Three things that matter here:
- It's a real Docker Registry V2 endpoint. No proprietary CLI, no plugin. Anything that speaks the registry API —
docker,podman,buildah,skopeo, Kaniko, a CI job — pushes to it the same way it pushes anywhere else. - The host is yours. Each account gets its own registry subdomain and repository name, so you aren't sharing a namespace or competing for image names.
- The credentials are generated, not your account login. They're scoped to that repository. The panel masks them on screen — hover to reveal, or use the Copy button.
Once the push lands, click I've pushed the image and the platform creates the application from it.
Why "registry and runtime in one place" is the actual win
Rate limits are the headline, but the more useful property is that the thing storing your image is the thing running it.
On a split setup — registry at Docker Hub or GHCR, runtime somewhere else — every deploy is a cross-provider pull that needs credentials configured on the runtime side, stays subject to the registry's quota, and fails in a way that's awkward to debug because the two systems don't share a view of what happened. Here the pull is internal. There's no imagePullSecret to rotate and no upstream quota between your image and your container.
It also means private is the default. You aren't publishing to a public registry and then remembering to make the repository private — there's no public index for it to appear in.
Deploying on push
Pushing a new tag doesn't restart anything by itself, which is what you want most of the time — you can push a build, look at it, and roll it out deliberately.
When you do want push-to-deploy, an existing app's Deployment tab has an Automatically deploy after push option. Ticking it changes the example tag it shows you: it appends _autodeploy to your tag. Push a tag ending in that suffix and the platform applies the image to the app and restarts it. Push any other tag and the image is just stored.
That's a deliberately blunt mechanism, and it's better for it — the tag name is the trigger, so which pushes deploy is visible in your build script rather than buried in a webhook configuration. In CI, tag the artifact you want live as :${SHA}_autodeploy and leave everything else untagged for deploy.
Note the option lives on the app's Deployment tab, not on the create-application flow — you'll see it after the app exists.
When to use this instead of the other deploy paths
JustRunMy.App has four ways in, and the Docker Push one is not always the right pick:
- Docker Push — you already build images in CI, or you want control over the exact image. Best when your build is tuned and you want the registry and runtime coupled.
- Git Push — you'd rather push source and let the platform build your Dockerfile. No local Docker needed.
- Zip upload — no Dockerfile at all; the AI agent works out the build from your source.
- Existing Image — the image already lives in a third-party registry and you just want it run. This is the one that does still pull from Docker Hub, quota and all.
A reasonable pattern: build in CI, push to the built-in registry, and keep third-party registries for upstream base images only.
FAQ
What are Docker Hub's pull rate limits?
100 pulls per 6 hours for unauthenticated users (counted per IPv4 address or IPv6 /64 subnet), 200 per 6 hours for free authenticated Personal accounts, and unlimited on Pro, Team, and Business plans.
Is there a pull limit on the built-in registry?
No. It's your account's own registry and the platform pulls from it internally when starting your app.
Are pushed images private?
Yes. The registry is per-account with generated credentials, and there's no public listing.
Can I push from CI instead of my laptop?
Yes — it's a standard Docker Registry V2 endpoint. Store the login credentials as pipeline secrets and run the same three commands. Any OCI-compatible tool works, not just the Docker CLI.
Does pushing a new image redeploy my app automatically?
Only if you opt in. Enable Automatically deploy after push on the app's Deployment tab and push a tag ending in _autodeploy; other tags are stored without restarting anything.
Do I still need a Docker Hub account?
Only for pulling public base images during your build — the FROM line in your Dockerfile. Your own application images never touch it.
Wrapping up
Registry rate limits are a tax you pay for a split that often has no reason to exist: images stored by one company, run by another. If the same system does both, the pull is internal, the credentials are scoped to one repository, and the images are private without you configuring anything. Build, push, run — and keep Docker Hub for what it's genuinely good at, which is distributing everyone else's base images.