Skip to main content
​
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.
  • 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 and the API reference.

​
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).