> ## Documentation Index > Fetch the complete documentation index at: https://docs.vertracloud.app/llms.txt > Use this file to discover all available pages before exploring further. # v26.4.9 — October 25, 2026 > v26.4.9: custom Docker images built from your own Dockerfile on Enterprise 28, 30 and 32, with versions, rollback, GitHub rebuilds and snapshots **v26.4.9** October 25, 2026 ### Custom Docker images Enterprise 28, Enterprise 30 and Enterprise 32 can now build an image from their own `Dockerfile` and run applications from it. Use it for another language or version, system packages, your own start process or ready-made apps. * **Create an image** from a ZIP file of up to 100 MB, or from a GitHub repository. The branch is optional: without it, the repository's default branch is used. A repository in your GitHub App installations is linked, so each push rebuilds the image; a public repository outside them is built once, with no link. In the panel, **New project** also has the **Use a Docker image** option to create an app from an image you already have. The project needs a file named exactly `Dockerfile` at its root. The image is built in an isolated build environment with a 26-minute limit, and the result can be up to 10 GB. Each account can have up to 20 images. * **Check before you build.** The panel reviews your `Dockerfile` before the build starts: instructions that would weaken the isolation of the build are refused, and common mistakes, like `.env` files in the project, are pointed out so you can fix them. `.env*` files never go into the image, and your `Dockerfile` is never rewritten. See [what is refused and what is warned about](https://docs.vertracloud.app/guides/custom-docker-images.md#what-is-refused-and-what-is-warned-about). * **Create apps from the image.** Several apps can share one image, each with its own variables. For a web app, the port is the first `EXPOSE` of the `Dockerfile`, or 80, and it reaches your app as `PORT`. An app created without web can be published later by informing the port. * **Update the image** by uploading a new context, by a commit on top of the current context, or by a push to a linked GitHub branch (link a repository from your GitHub App installations; the branch is optional). The GitHub Action accepts `image-id` to rebuild an image. A rebuild never restarts your applications: each app moves to the new version when you restart or deploy it. * **Versions and rollback.** Every successful build is a version. Apps keep 30 releases for 30 days, and a rollback starts a version that was already built. * **Snapshots** of these apps hold the data of `/app` and the image version. When you restore, you can also go back to that version if it still exists. * **Rename and describe.** Give an image a description (up to 128 characters) when you create it, and rename it or change its description later in the panel, the API, the SDKs, the CLI, the MCP server or the VS Code extension. Nothing is rebuilt and your applications keep running. * **Deleting an image** deletes every application created from it, after you type the image name. * **In the VS Code extension.** A new Docker images view lists your images and their apps. From it you can create an image from a folder or a GitHub repository, rebuild it, follow the build log, browse versions, link a GitHub branch, delete it and create an app from it. Deploying, publishing and restoring snapshots of image apps also work from the extension, and a new app from a folder with a `Dockerfile` offers to create an image instead. New API routes under `/v1/images` (including `PATCH /v1/images/{image_id}` to rename and describe) and `POST /v1/apps/image`, with the new `images:read`, `images:write` and `images:delete` API key scopes (deleting an image that has apps also needs `apps:delete`, and uploading files to an app that runs an image also needs `images:write`), and the new error codes `PLAN_DOES_NOT_SUPPORT_CUSTOM_IMAGES`, `MAX_IMAGES_REACHED`, `IMAGE_NOT_FOUND`, `IMAGE_VERSION_NOT_FOUND`, `IMAGE_BUILD_IN_PROGRESS`, `IMAGE_NOT_READY`, `IMAGE_BUILDER_UNAVAILABLE`, `IMAGE_CONTEXT_TOO_LARGE`, `IMAGE_NAME_MISMATCH`, `IMAGE_TOO_LARGE`, `IMAGE_LABEL_REFUSED`, `IMAGE_VOLUME_REFUSED`, `IMAGE_APP_PORT_REQUIRED`, `IMAGE_APP_FIELD_NOT_APPLICABLE`, `IMAGE_APP_CODE_NOT_APPLICABLE`, `DOCKERFILE_NOT_FOUND` and `DOCKERFILE_REFUSED`. Read the [guide](https://docs.vertracloud.app/guides/custom-docker-images.md) and the [API reference](https://docs.vertracloud.app/api-reference/endpoint/images/create.md). ### Improvements * **Choose the branch of your GitHub deploys.** Importing a repository from GitHub in the panel now has a branch selector, and automatic deploy follows the branch you pick (the deploy webhook route accepts an optional `branch`). Existing automatic deploys keep following `main` and `master`. * **Developer links in the sidebar.** CLI, VS Code extension, MCP, What's new and Docs moved from the account menu to the panel's sidebar. * **One-click theme.** Appearance in the account menu is now a single button that cycles through System, Light and Dark. * **Deleting an application waits for the result.** The confirmation dialog stays open with its progress until the deletion is done, then closes with the application already gone from the list. If the deletion fails, the dialog stays open and shows the reason. * **Already signed in.** Opening the sign-in page while signed in takes you straight to the dashboard. ### Fixes * Importing a GitHub repository whose name contains `.git` in the middle, like `name.github.io`, no longer fetches the wrong repository. * Restoring a snapshot (application or database) or rolling back to a release from a damaged file is now refused before anything changes (`INVALID_ZIP_STRUCTURE`, `400`). The application's files and the running database stay as they were; before, a database could be left stopped and an application's files could be erased. An application snapshot with no files is refused the same way. * Actions on applications, databases, snapshots, domains and files now always record their activity in the workspace the resource belongs to. * Connecting an application to automatic deploy now checks the repository against your GitHub App installation. A `repo_id` that does not match the repository is refused with `VALIDATION_ERROR`, a repository outside the installation returns `INSTALLATION_NOT_FOUND`, and GitHub being unavailable returns `FETCH_ZIP_ERROR` (`502`). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.