Upload the project
A ZIP or a GitHub repository, with the branch you choose, and a file named Dockerfile at the root. The dashboard shows what will be refused before the build starts.
Docker images
Bring your Dockerfile. Run any stack.
Your language, your system packages, your own start process. Upload the project, Vertra builds the image in an isolated environment, and you launch as many apps from it as you like.
Who it is for
For when the language list is not enough.
Managed runtimes cover the most common languages. If you need another language or version, system packages, your own start process or an app that already ships as an image, a Dockerfile does it. Everything stays in the same dashboard, with the same logs, metrics, domains and snapshots as your other apps.
How it works
Three steps, from Dockerfile to a live app.
No build server to maintain and no image to publish anywhere.
Vertra builds the image
The build runs in an isolated environment, with a live log in the dashboard. If it fails, the version that was already live stays untouched.
Create as many apps as you want
Each app starts from the same image with its own RAM, port and environment variables. A bot, an API and a worker can all come from one Dockerfile.
Benefits
Freedom of stack, with the comfort of the platform.
What you already have on regular apps also applies to image apps.
Any language or stack
Including the ones that are not on the runtime list: if it runs in a Linux container, it runs here.
Automatic GitHub deploys
Link the image to a repository and a branch. Every push rebuilds the image, without opening the dashboard.
Versions with rollback
Every successful build becomes a version. Going back to a previous one is instant, because it is already built.
Snapshots of your data
The app's persistent disk is part of backups and snapshots, with scheduling, retention and restore just like other apps.
Live build logs
Follow each build step in the dashboard as it happens and reread the log later if something fails.
Many apps per image
Build the image once and create as many apps as you need, each with its own configuration.
Security
Freedom for your code, isolation for everyone.
You write the Dockerfile. The platform makes sure it affects nobody else.
The build runs isolated
Every build happens in an environment separate from the platform and from other customers, with time and resource limits.
Apps run in the same sandbox as everyone else
An image app gets the same protection as any Vertra app: a container isolated from other customers.
Secrets stay out of the image
Your .env files never enter the build context or the image. Variables live on the app, where you change a value without rebuilding.
A rebuild never takes anything down
A new version never restarts apps by itself, and a failed build does not change what is running. An app only changes version when you ask.
Rules
What the platform refuses and how the app runs.
The dashboard checks the Dockerfile before the build and explains each refusal. The main ones are below; see the full guide in the docs.
Dockerfile at the root, with that name
A ZIP of up to 100 MB or a GitHub repository, with a file named exactly Dockerfile at the root. The image is linux/amd64.
Directives that would break isolation
A # syntax= that points to a third-party frontend, RUN --network=host and RUN --security=insecure are refused. Remove the directive and the build goes on.
No secrets inside the build
Secret and ssh mounts (--mount=type=secret and --mount=type=ssh) are refused. Put keys in the app's variables.
.env does not go into the image
The .env files are removed from the context. Their keys become suggested variables when you create the app, and the values never enter the image.
/app is the persistent disk
What the app writes to /app stays across restarts and goes into snapshots. Avoid WORKDIR /app: what the image puts there is hidden by the disk. Use another folder, such as /srv.
Port, user and writes
The app listens on the port of the first EXPOSE (or 80) and receives the value in PORT. It runs as user 1000:1000, and outside /app only temporary folders, such as /tmp, accept writes.
Example
A regular Dockerfile is enough.
No special instruction: the platform uses your Dockerfile exactly as you wrote it, without rewriting anything.
Dockerfile
FROM python:3.12-slim
WORKDIR /srv
COPY . .
RUN pip install -r requirements.txt
EXPOSE 8000
CMD ["python", "main.py"]Plans
Available on Enterprise 28, 30 and 32.
Up to 20 images per account, counting images in any state. Rebuilding, committing and creating versions does not count as a new image.
| Plan | Images |
|---|---|
| Enterprise 28 | 20 images |
| Enterprise 30 | 20 images |
| Enterprise 32 | 20 images |
If you move to a plan without the feature, the images and apps you already have keep running. You just cannot create or rebuild images until you return to one of these plans, and deleting is always allowed.
Compare plansQuestions
Frequently asked questions
The essentials before you upload your first Dockerfile.
Do I need to know Docker?
Only the basics: a Dockerfile that builds and starts your app. If you already run the project in a container on your machine, the same Dockerfile usually works here.
When should I use an image instead of a managed runtime?
When the managed runtime does not cover what you need: another language or version, system packages, your own start process or an app that already ships as an image. For the languages on the list, deploying by ZIP or GitHub is simpler.
Can I update the image later?
Yes. You can upload the context again, commit files on top of the current one, or link the image to a repository and let every push rebuild it. Apps only move to the new version when you restart or deploy.
What happens to my app's data?
Everything the app writes to /app stays on the persistent disk and goes into snapshots. The image itself is not in the snapshot, because its code already has history in the versions. When you restore, you choose whether to go back to the image version too.
Why was my Dockerfile refused?
The dashboard lists each point. The most common causes are a third-party # syntax=, RUN --network=host, RUN --security=insecure and secret or ssh mounts. Remove the directive and upload again.
What happens if I delete an image?
The image, its versions and every app created from it are deleted, and you confirm by typing the name. Each app follows the usual deletion rules, including the safety snapshot on plans that have it.
Docker images
Your Dockerfile live in minutes.
Upload the project, follow the build live and create the first app from the image.