Deploy a Docker image on blitz.cloud

You can deploy any public Docker image that is built for amd64, from Docker Hub, GitHub's registry (ghcr.io), Quay or another public registry. In the dashboard, click "Host something new", choose "An app from Docker Hub", search for the image by name or type its full name, pick a tag and a subdomain, and blitz.cloud works out the port and runs the container with HTTPS in front of it.

Requirements for the image

Root is fine. Every app runs in its own gVisor sandbox, so an image that starts as root, like the official nginx, runs as root inside that sandbox and nowhere else. An image that names a user runs as that user. The wizard tells you when an image runs as root.

An app you deployed before 25 September 2026 keeps running as uid 1000 until it restarts. Restart it once from its page and it starts as its image expects.

Step by step

1. Open dashboard.blitz.cloud and click "Host something new".
2. Choose "An app from Docker Hub" and type part of the name, for example uptime-kuma or yourname/yourapp. The wizard searches Docker Hub as you type, and official images are marked. For another registry, type the full name, such as ghcr.io/yourname/yourapp.
3. Pick a tag. The wizard lists the image's real tags and preselects the one that follows new releases, like latest or a major version.
4. Give the app a short name. That becomes the subdomain: backend turns into backend.<you>.blitz.cloud.
5. Check what blitz.cloud detected, then click "Put it online".

A repository you pushed a few minutes ago may not show up in Docker Hub search right away. Docker Hub indexes new repositories with some delay.

What blitz.cloud detects

When you pick an image, we read what the image declares about itself: exposed ports, volumes and environment variable names. A language model then fills in what metadata can't tell, such as "WordPress wants MariaDB and reads WORDPRESS_DB_HOST". The image stays the authority on its own ports. If the model suggests a port the image doesn't expose, the image wins.

The port is chosen in this order:

1. A port the image declares with EXPOSE
2. If it declares several: 80, 8080, 3000, 8000, 5000, otherwise the lowest
3. If it declares none, the model's suggestion
4. If nothing is known, 80

You can override the port, the database and the kept folders under "Advanced settings" in the wizard. It's closed by default because most images don't need it.

Environment variables

Set environment variables on the app's Environment tab. They are encrypted before they are stored, and each app can have up to 64. Changes apply the next time the app restarts, and the restart button is right next to that sentence. See settings and files.

Databases

If the image needs a database, blitz.cloud can create one and inject the connection details as environment variables. Where the variable names are known, they are filled in for you and shown before anything is applied. If they aren't known, the app gets DATABASE_URL. See databases.

Persistent storage

Folders the image declares as volumes, plus any the detection adds, survive restarts. An app from a pasted image can keep up to 6 folders and reserves 1 GB of your storage. On Pro these folders are copied every night. On the free plan only databases are.

Health checks

For a Docker image we check whether the port accepts connections before sending traffic to it. There's no automatic restart for pasted images, because restarting an app nobody has vetted can break something that was working. Apps from the App Store get a proper HTTP check and are restarted if they stop answering.

Automatic updates

With automatic updates switched on (the default for a moving tag such as latest or alpine), we look every night around 4:00 UTC at where the tag points. The first night only records it. From then on, when the tag has moved to a newer build, we put that exact version online, pinned by its digest, so what runs is what was checked. If the new version does not start within ten minutes, we put the version before back, say so on the Activity tab, and switch automatic updates off for that app until you turn them on again.

While the new version starts, the app shows Updating and the version before keeps running. We send you a mail after each overnight update. You can switch that off under Settings > Notifications.

The check works for images on Docker Hub, GitHub's registry (ghcr.io), Quay, lscr.io, GitLab, and the public registries of Amazon and Microsoft. The app's Settings tab says so when an image is somewhere else.

Common problems

• The app stays on "Starting": it is probably listening on a different port than the one chosen. Change it under Port on the app's Settings tab.
• "This app wants to run as root": the app was set up before root was allowed. Restart it and it starts as root, inside its sandbox.
• "Needs attention" with a crash loop: read the last log lines shown on the page. Missing environment variables and writes to read-protected folders are the usual causes.
• "There is no room on blitz.cloud for this app right now": the cluster is full. We add servers when this happens, so try again later.

More in app status and logs.

Can I deploy from GitHub instead?

Yes. Paste the link of a public repository and we build the code and put it online. Connect your GitHub account and your private repositories work too, with a new version online on every push. See deploy a GitHub project.