Deploy a Docker image on blitz.cloud

You can deploy any public Docker image from Docker Hub that is built for amd64. In the dashboard, click "Host something new", choose "An app that is already packaged up", search for the image by 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

The root rule is the one people hit most. Many official images start as root and switch users inside their entrypoint, or write to system folders on startup. Those stop on blitz.cloud. Look for an "unprivileged" or "rootless" variant, for example nginxinc/nginx-unprivileged instead of nginx.

We recommend images that listen on a port above 1024, such as 8080. A non-root process usually can't bind port 80.

Step by step

1. Open beta.blitz.cloud and click "Host something new".
2. Choose "An app that is already packaged up" and type part of the name, for example uptime-kuma or yourname/yourapp. Official images are marked.
3. Pick a tag. The wizard lists real tags from Docker Hub 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. Files are not backed up yet, 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.

Common problems

• The app stays on "Starting": it is probably listening on a different port than the one chosen. The dashboard can't change the port of an existing app yet, so delete the app and deploy it again with the right port under Advanced settings.
• "This app insists on running with full access to the machine": the image needs root. Use a non-root variant.
• "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, for a public repository: paste its link and we build the code and put it online. See deploy a GitHub project. Private repositories and redeploying on every push need your GitHub account connected, which is not switched on yet (what's live).