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, no Kubernetes manifests to write. This walks through deploying 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.
One thing worth being upfront about: 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, 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 instead. In practice that covers the large majority of “deploy this container” needs: 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.apphostname 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 managed registry it manages for you. That’s true whether the container underneath 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.
What isn’t available yet is connecting your own existing registry (Docker Hub, a bare ECR repository, GCR, ACR) and pointing a deployment at an image that’s already sitting there. 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, 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 (installable 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, no Dockerfile required.
Step 3: set the port your container listens on
Tell Ownkube which port your container’s process binds to internally. This is the one setting a containerized deploy can’t skip, get it wrong and the health check and public hostname both fail to find your app.
Container port: 8080Step 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=infoVariables are set per deployment. If you’re running the same image in more than one environment (staging and production, for instance), set them again in each; 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: 3sWithout one, Ownkube can only infer that the container process is running, not that it’s actually able to 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 usage, both CPU and memory, 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 (shared CPU, from $5 a month) or a Core box (dedicated CPU, from $58 a month), that bills a flat rate whether it’s busy or idle. Pick this for a container that runs hot continuously, a queue worker that’s always processing something, where the flat price is more predictable than watching a meter.
Both modes draw from the same prepaid wallet, so switching a deployment from metered to reserved (or back) later doesn’t change how you pay, only what you’re billed for.
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. No certificate to request, no DNS record to add for this default hostname.
https://your-app-a1b2c3.ownkube.appCustom domains (pointing your own domain at the app) are on the roadmap for Ownkube Compute specifically; they’re shipped today on the own-cloud (BYOC) path if you’re running on your own AWS account instead.
What happens on the next push
Every subsequent 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, 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
Nothing about deploying from a Dockerfile locks you into Ownkube-managed compute specifically. 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’s the option to have in your pocket if a workload eventually needs to sit inside a specific AWS account rather than Ownkube’s shared compute. If you’re weighing that decision now, our comparison of Fly.io and running your own AWS walks through when that tradeoff is worth making.
For teams evaluating platforms broadly rather than just this one workflow, Railway vs Render vs Northflank is a useful side-by-side if Docker deploys are one requirement among several you’re comparing.
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, Ownkube builds it 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, no Dockerfile required either way.
What if my repo has more than one Dockerfile?
You pick which one at deploy time, 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, no certificate request or DNS record needed for that default hostname.
Where Ownkube fits
If your app is already containerized, getting it running is a Dockerfile, a port, and a health check away, 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. Deploy your first app.
