Hand us a built app. Get back a live web address.
You give the platform an image name and a port. It pulls the image, runs it on a host that is yours alone, and puts it behind a certificate on an address of its own.
Storage inside a container is wiped when it restarts. You should know that before you buy, not after.
- A machine of your own. 2 vCPU, 4 GB of memory and 40 GB of disk on the smallest plan, shared with nobody.
- Room for more than one app. Up to 5, 20 or 100 containers on a single host, depending on the plan.
- A secure address, made for you. The certificate and the DNS record are created when the host is built. You configure neither.
- No transfer allowance to watch. Container plans are not metered for bandwidth, so there is no cap to cross and no overage to be billed.
Four steps, and you perform one of them.
The platform pulls a container image that has already been built, so there is no build to configure, no language runtime to choose and nothing to compile on our side. That is also why moving here is cheap: the image you run somewhere else runs here unchanged.
- Image format
- Any standard OCI container image, referenced as a name and a tag. Public registries only: there is no private registry sign-in.
- What you provide
- image, name, subdomain, port, processor limit (optional), memory limit (optional)
- Ports
- One exposed port per container, from 1 to 65535. More than one port on a single container is not supported.
- Resource limits
- A processor limit as a decimal and a memory limit as a size, both optional, applied to each container.
- Certificates and DNS
- Issued automatically. An address record for the host and a wildcard record beneath it are created when the host is provisioned.
- Logs
- Streamed live from the container, opening on the last 100 lines.
- Moving from another platform
- A pre-built image runs here unchanged, because the platform pulls the image rather than rebuilding it. In practice the move is the image reference, the port and the environment variables.
- Bandwidth
- Not metered and not capped on container plans. There is no transfer allowance to publish, so none is published and none can be exceeded.
Anything a container writes to its own disk is gone when it restarts.
This is how containers behave everywhere, and it is the one thing that surprises people who have not run them before. It is on this page rather than in the panel after you have paid.
Outside the container: a database, an object store, or any service you reach over the network. The deploy form says the same thing at the moment you first use it.
There is no persistent volume you can attach to a container here. If your app needs a disk it keeps, this is the wrong product and a server is the right one.You restarting it, a new deploy under the same name, or the host rebooting. A container that stops on its own is brought back up by the host.
There is no deploy history and no one click rollback to a previous image. Going back means naming the tag you want and deploying it again.No. This product pulls an image that is already built. That is exactly why moving here costs almost nothing, and why there is no build configuration to get wrong.
If you would rather push a branch than name an image, that is a different product of ours and it is linked at the bottom of this page.Pick the host, not the app count.
Every figure below is the machine the platform actually builds, and the container cap is a hard number rather than a guideline. The prices were read from the catalogue in your own currency when this page loaded.
The monthly price is the monthly price. There is no introductory rate on this page and nothing changes at renewal, which is clause 7.5 of the Terms rather than a promise made in marketing. Your host is built for you after you order, and you get an email when it is ready.