How to deploy a web app on Ownkube in under a minute

Connect a repository, pick a region, and Ownkube gives you a live HTTPS URL before the coffee finishes brewing. There is no cloud account to set up first, no YAML to write, and no server to provision by hand.

This walks through the whole path on Ownkube Compute, the managed infrastructure Ownkube runs for you: from an empty dashboard to a running app with a real TLS certificate on it.

TL;DR

• Sign in to app.ownkube.io, connect a GitHub or GitLab repo (or point at an image), and deploy.
• If your repo has a Dockerfile, Ownkube builds from it. If it does not, Ownkube detects the language and builds automatically.
• You get a live URL on an auto-allocated *.ownkube.app hostname with TLS already on, no certificate setup required.
• No cloud account, no config file, and no card to start.
• Every following git push rebuilds and rolls out with zero downtime.

What you need

• An Ownkube account (sign in at app.ownkube.io).
• A GitHub or GitLab repository with a web app in it, or a container image if you would rather deploy from one.
• Nothing from AWS, GCP, or Azure. Ownkube Compute is Ownkube-managed infrastructure, so there is no cloud account to connect for this path.

Step 1: Sign in and start a deployment

Sign in to the dashboard at app.ownkube.io and start a new deployment. This is the primary way to work with Ownkube: one dashboard for connecting a repo, watching a build, and reading logs after it ships.

Step 2: Point it at your code

Connect your GitHub or GitLab account and pick the repository and branch to deploy. From here Ownkube decides how to build the image:

• Repo has a Dockerfile: Ownkube builds from it. If there is more than one Dockerfile in the repo, you pick which one.
• Repo has no Dockerfile: Ownkube detects the language and framework and builds the image automatically. The dashboard shows this as the “Auto” build target, so you can see which path a given deployment is using.

Either way, the build runs on Ownkube’s side and the resulting image is pushed to a managed registry, so you never have to stand up your own container registry for this.

Step 3: Pick a region and deploy

Choose a region and start the deploy. Ownkube provisions the deployment on Compute, allocates a public hostname on the shared *.ownkube.app domain, and terminates TLS on it automatically. There is no certificate to request or renew and no DNS record to create for this step: the hostname and the certificate both exist the moment the deployment is ready.

Step 4: Watch it go live

The dashboard shows the build running, then the rollout. When it finishes, you get a URL you can open right away, already serving over HTTPS. For a small web app this whole path, from connecting the repo to a working URL, typically takes under a minute.

You can also check on a deployment from a terminal with the okctl CLI (brew install ownkube/tap/okctl, then okctl login to authenticate in your browser):

okctl login
okctl deploy list
okctl deploy status <deployment-id>

status reports build sync, health, and whether the URL is ready to serve traffic, which is useful if you are scripting a deploy or wiring it into an agent.

Step 5: Ship your next change

Push a commit to the connected branch and Ownkube rebuilds the image and rolls the new version out with zero downtime: the old version keeps serving traffic until the new one is healthy. If a deploy goes wrong, the dashboard’s rollback control puts the previous version back in front of traffic.

If something looks off after a rollout, pull the recent logs without leaving your terminal:

okctl deploy logs <deployment-id> --range 600

That fetches log entries from the last ten minutes (--range is in seconds), which is usually enough to see whether a bad deploy is a build problem or a runtime one.

Moving it later, without a rewrite

Ownkube Compute is the fast path: no cloud account, nothing to provision. If you later want your own data boundary or your own AWS bill for this same app, you can connect an AWS account and run the identical app there, with no rewrite. The build, the dashboard, the logs, and the metrics all carry over. That option is worth knowing about, not something you need to think about on day one. If you are actively weighing platforms, our comparison of Railway, Render, and Northflank covers how each handles this kind of portability.

What to add next

A web app rarely stands alone. Once this deployment is live, the two most common next additions are a database and a cache:

• How to add a managed Postgres database to your app
• How to add a Valkey (Redis) cache to your app

Both attach to the app you just deployed, and both draw from the same wallet as your Compute usage, so there is nothing extra to set up on the billing side.

FAQ

Do I need a Dockerfile to deploy?

No. If your repo has one, Ownkube builds from it. If it does not, Ownkube detects the language and framework and builds the image automatically. Both paths land on the same managed registry and deployment flow.

Do I need to connect a cloud account first?

No. Ownkube Compute is managed infrastructure that Ownkube runs, so deploying an app does not require an AWS, GCP, or Azure account. Connecting your own AWS account is a separate, optional path for later.

Can I use my own domain instead of the ownkube.app hostname?

Custom domains are shipped for apps running on your own AWS account (Starter clusters), where you register a domain once and Ownkube manages a certificate covering it. On Ownkube Compute, today’s deployments get the auto-allocated *.ownkube.app hostname with TLS on by default.

What happens when I push a new commit?

Ownkube rebuilds the image and rolls the new version out with zero downtime, so the previous version keeps serving requests until the new one passes its health check. You can roll back to the prior version from the dashboard if needed.

How fast is “under a minute”, really?

It depends on your build (a larger dependency tree takes longer to build than a small script), but for a typical small web app the path from connecting a repo to a live, TLS-covered URL is around a minute end to end.

Where Ownkube fits

If you want a running, HTTPS-covered app without touching a cloud console first, this is the whole setup: connect a repo, pick a region, and deploy. The build, the certificate, and the hostname are handled for you, and every push after that just rolls forward. Deploy your first app.