Deploy a GitHub project on blitz.cloud

Paste a link to any public GitHub repository and blitz.cloud clones it, builds it and runs the result under your address with HTTPS. It does not have to be your repository. If the project has a Dockerfile we use it; if it does not, we work out how to build it from what is in the repo.

Step by step

1. Open beta.blitz.cloud and click "Host something new".
2. Choose "My own code".
3. Paste the link, for example github.com/docker/welcome-to-docker, and click Continue.
4. Give the app a short name. That becomes the subdomain: demo turns into demo.<you>.blitz.cloud.
5. Click "Build it and put it online" and watch it happen.

The first build takes a few minutes, because everything the project needs is downloaded from scratch. Later builds of the same project reuse the layers that did not change.

How the build works

Both run in a sandbox with no access to anything of ours or anyone else's. A build can reach the internet to download dependencies, and nothing on the private network.

Once a project has been built, the plan is remembered against that exact commit. If somebody else deploys the same public project at the same commit, their build starts from what we already worked out. Plans from private repositories are never shared.

Which port your app listens on

We tell your app to listen on 8080 through the PORT environment variable, which is what a generated build uses. If your Dockerfile declares a different port with EXPOSE, we read that from the image after the first build and use it instead.

Your app has to listen on a port above 1024. Every app here runs as uid 1000 with all Linux capabilities dropped, and a non-root process cannot bind port 80.

When your code changes

Click "Get the newest code" on the app's page. It builds whatever is newest on the branch and puts it online. The version currently running stays up until the new one works, so a build that fails changes nothing.

Redeploying automatically on every push needs your GitHub account connected, which is not switched on yet. See what's live.

Private repositories

Not yet either. Connecting a GitHub account is what makes private projects visible to us, and it opens together with automatic redeploys. Today the project has to be public.

Environment variables and databases

Set environment variables on the app's Environment tab after the first deploy. They are encrypted before they are stored and applied on the next restart. See settings and files.

A managed database is created from the Databases page and connected to the app there. Detection of what a project needs runs for Docker images, not for source builds, so a project that needs PostgreSQL gets it when you say so rather than automatically. See databases.

Common problems

• "We could not find a Dockerfile in this project": the project has no Dockerfile and the detection could not work out how to build it either. Adding a Dockerfile to the repository is the reliable fix.
• The build fails while installing dependencies: the log below the failure has what the installer said. A lockfile that does not match the manifest is the usual cause.
• "This build ran out of memory": a build gets 2 GB. Large frontend builds sometimes need more; get in touch and we will look at it.
• The app is "Starting" and never answers: it is listening somewhere other than the port we are sending traffic to. Make it read PORT, or add EXPOSE to the Dockerfile and deploy again.
• "Part of this project is built for a different kind of processor": our servers are x86. A base image that only exists for arm64 will not run.

The build log sits under the Deployments tab of the app, under the line it belongs to, and stays there afterwards.

Monorepos

One project, one app, built from the repository root. Choosing a sub-directory is not possible yet.