If your app already runs in a container, Ownkube builds it from your Dockerfile and runs it with a public URL, TLS, health checks, and autoscaling attached, without any Kubernetes manifests to write. This guide deploys a Dockerfile-based app end to end: connecting the repo, setting the port and environment variables, adding a health check, and choosing between metered and reserved pricing.

Today the shipped path to a running container is a Dockerfile in a connected GitHub or GitLab repository, which Ownkube builds and pushes to a managed registry for you. Pulling a prebuilt image straight from an external registry like Docker Hub or a bare ECR repo is on the roadmap and not available yet.

If your image already exists somewhere else, put its Dockerfile (or the source it’s built from) in a repo and point Ownkube at that. That covers most “deploy this container” needs, because anything you can express as a Dockerfile, Ownkube can build and run.

TL;DR

Connect a GitHub or GitLab repo with a Dockerfile. Ownkube builds the image and pushes it to a managed ECR it runs for you, no registry account of your own required.
If the repo has more than one Dockerfile, you pick which one at deploy time. If it has none, Ownkube’s automatic build detects the language and builds it for you instead.
Set the port your container listens on, add environment variables, and point a health check at a real endpoint before you call it done.
Every deployment gets an auto-allocated *.ownkube.app hostname with automatic TLS the moment it’s live.
Choose metered pricing (bills on actual CPU and memory usage, cheapest for anything that idles) or a flat reserved box (predictable price, better for a workload that runs hot around the clock), per deployment.
Pulling a prebuilt image from an external registry isn’t shipped yet. Deploying from a Dockerfile in a repo is the way to get any containerized app running today.

What “any Docker image” means on Ownkube right now

A Dockerfile is a complete, portable recipe for an image: FROM, your dependencies, your COPY, your CMD. If you can build an image locally with docker build, that same Dockerfile is what Ownkube needs. It runs the identical build server-side and pushes the result to the registry it manages for you.

That holds whether the container is a Node API, a Go binary, a Python worker, or a piece of open-source software you’re self-hosting. If it builds from a Dockerfile, it deploys the same way.

Connecting your own existing registry (Docker Hub, a bare ECR repository, GCR, ACR) and pointing a deployment at an image that’s already there is not available yet. The registry-connect screen exists in the UI as a “coming soon” placeholder for every provider.

Until that ships, get the image’s Dockerfile into a repo Ownkube can build from. For most self-hosted tools this is trivial, because the project’s own repo usually already has one.

Before you start

A GitHub or GitLab repository with a working Dockerfile (or no Dockerfile at all, if you want Ownkube’s automatic build to detect the language for you).
The port your container listens on internally.
Any environment variables or secrets the app needs at runtime.

Step 1: connect your repository

From the Ownkube dashboard, start a new deployment and connect the repository if you haven’t already.

GitHub goes through the GitHub App, which you can install on more than one account or organization per Ownkube org, so a personal repo and a work org can both connect. GitLab goes through a direct account connection. Personal access tokens work for either if you’d rather not install an app.

Step 2: choose the build target

Deploy new -> Web service
Source: your-org/your-repo
Branch: main
Build target: Dockerfile (api/Dockerfile)

If the repo has a Dockerfile, Ownkube builds from it, and if there’s more than one, you choose which. If there’s none, the deploy flow switches to Auto: Ownkube detects the language and builds the image itself.

Step 3: set the port your container listens on

Tell Ownkube which port your container’s process binds to internally. A containerized deploy can’t skip this setting. If it’s wrong, the health check and the public hostname both fail to find your app.

Container port: 8080

Step 4: add environment variables

Set the environment variables your container reads at runtime on the deployment’s Environment tab.

DATABASE_URL=postgres://...
NODE_ENV=production
LOG_LEVEL=info

Variables are set per deployment. If you run the same image in more than one environment (staging and production, for instance), set them again in each, since there’s no shared, environment-wide variable set yet.

Step 5: configure a health check

On the deployment’s Settings tab, under Health checks, point the readiness and liveness probes at a real endpoint your container serves.

Health check path: /health
Initial delay: 5s
Timeout: 3s

Without one, Ownkube can only tell that the container process is running, which says nothing about whether it can serve a request. A health check is what keeps a slow-starting database migration from getting real traffic before it’s ready.

Step 6: choose metered or reserved pricing

Every deployment on Ownkube Compute picks one of two billing modes, and you can switch later.

Metered is the default and fits most containerized apps. You set CPU and memory limits as ceilings, and the bill follows actual CPU and memory usage per minute. A container that idles most of the day (a small API, a side project) costs almost nothing on the CPU line while it’s quiet.

Reserved puts the deployment on a fixed-size box, a Spark box (from $5 a month) or a Core box (dedicated vCPU, from $58 a month), that bills a flat rate whether it’s busy or idle. Pick it for a container that runs hot continuously, like a queue worker that’s always processing something, where a flat price is easier to plan around than a meter.

Both modes draw from the same prepaid wallet. Switching a deployment from metered to reserved (or back) changes what you’re billed for and leaves how you pay the same.

Step 7: deploy and check the public URL

Once the build finishes and the health check passes, the deployment’s Overview tab shows its public hostname: an auto-allocated *.ownkube.app domain with automatic TLS issued the moment it goes live. For this default hostname you don’t request a certificate or add a DNS record.

https://your-app-a1b2c3.ownkube.app

Custom domains (pointing your own domain at the app) are on the roadmap for Ownkube Compute specifically; they’re shipped today on Starter clusters in your own AWS account.

What happens on the next push

Every later push to the connected branch triggers a new build and a zero-downtime rollout. The old container keeps serving traffic until the new one passes its health check, and then traffic switches over. If a build or rollout goes wrong, roll back to the previous revision from the deployment’s Revisions tab.

Moving the same container to your own AWS later

Deploying from a Dockerfile keeps you portable. The same app, built the same way, can move to your own (or a customer’s) AWS account later with no rewrite, and its logs, metrics, and health checks come with it.

That option matters if a workload eventually needs to sit inside a specific AWS account rather than Ownkube’s shared compute. If you’re weighing that now, our guide to moving an app into your own AWS covers when the tradeoff is worth making.

If Docker deploys are one requirement among several you’re comparing, Railway vs Render vs Northflank is a useful side-by-side.

FAQ

Can I deploy a prebuilt Docker image straight from Docker Hub or ECR?

Not yet. Connecting an external registry is on the roadmap and shows as a “coming soon” stub in the UI today. The shipped path is a Dockerfile in a connected GitHub or GitLab repo, which Ownkube builds and pushes to a managed registry for you.

Does my repo need a Dockerfile?

No. If it has one, Ownkube builds from it. If it doesn’t, Ownkube’s automatic build detects the language and builds the image for you.

What if my repo has more than one Dockerfile?

You pick which one at deploy time, which is useful for a monorepo with separate services under different paths.

How do I choose between metered and reserved pricing?

Metered fits a container that idles some of the time, since CPU cost drops close to zero while it’s quiet. Reserved fits a container that runs continuously at similar load, since a flat box gives you a price that doesn’t move. You choose per deployment and can switch later.

Does the deployment get HTTPS automatically?

Yes. Every deployment gets an auto-allocated *.ownkube.app hostname with automatic TLS the moment it’s live, with no certificate request or DNS record needed for that default hostname.

For registry setup and image pull details, see the Registries reference in the docs.

Where Ownkube fits

If your app is already containerized, a Dockerfile, a port and a health check get it running, with a live TLS URL attached before you’ve thought about a certificate. The one gap to plan around today is pulling an image straight from an external registry; until that ships, a Dockerfile in a repo gets you the same result for almost any container.

See Ownkube pricing for the per-minute wallet model, from $5 a month. Deploy my first app.

How to deploy any Docker image on Ownkube