How to deploy a Docker container to a public URL

What "deploying a container" actually involves

Running a container in production normally means more than docker run. You need a host that's always on, a way to restart the container if it crashes, a public address, TLS certificates so it's served over HTTPS, and ideally more than one machine so a single failure doesn't take you offline. Wiring that up by hand — a VPS, a reverse proxy, a certificate renewer, a process supervisor — is the part nobody enjoys.

Sinkron does that part for you. You hand it a container image and the port your app listens on; it runs the container across independent machines behind one load-balanced HTTPS URL, keeps it alive with health checks and automatic restarts, and bills you by the second of runtime instead of a flat monthly server fee.

What you need first

• A container image. Anything that builds into a standard OCI/Docker image works — any language, any base. If you can docker build it, you can run it here.
• A pushed image, or a public one. Push your image to a registry (Docker Hub, GHCR, or a private registry — you can store private registry credentials in your account). To just try it out, use a public image like nginxdemos/hello.
• The port your app listens on. Your container should bind to 0.0.0.0 on a known port (say 8080), not 127.0.0.1, so traffic can reach it.

Deploy it in four steps

1. Make sure your image is reachable

Build and push your image to a registry. If it's private, add the registry credentials to your account once and Sinkron will pull from it on every deploy. Public images need nothing extra.

2. Add a little funding

Top up a balance by card or USDC — no subscription, no minimum. You spend it down as the container runs, and whatever you don't use stays yours and is withdrawable.

3. Create a session

Point Sinkron at your image, set a CPU/RAM footprint, tell it the port your app listens on, and choose how many runners you want. One runner is fine to start; more than one spreads the same app across several machines so it stays up if one drops. The quickstart walks through the exact screen.

4. Get your URL

Within seconds your container is live at https://<your-slug>.apps.sinkron.network — certificate, load balancing, and restarts all handled. Rename the slug any time. There's no server to provision, no reverse proxy to configure, no certificate to renew.

A few things that trip people up

• Bind to 0.0.0.0. A container listening on localhost only accepts traffic from inside itself, so it'll look "up" but be unreachable.
• Keep state outside the container. Treat the filesystem as disposable — a restart or a move to another machine starts fresh. Put your database, uploads, and anything you need to keep in an external store (a managed DB, or object storage with your own S3 keys).
• Make the image small and self-contained. It should start with one command and not depend on anything installed on the host.

What it costs

You pay for the CPU and RAM your container uses, by the second it runs — typically pennies an hour for a small app. It's free to sign up and look around, and because you're billed for actual runtime rather than a flat monthly box, a low-traffic container usually comes out cheaper than the standard $5 VPS that bills around the clock whether it's busy or idle. See how pricing works or the side-by-side with a $5 VPS.

When a plain VPS is still the better call

We'd rather be straight with you. A VPS or dedicated box is the better fit if your container needs persistent local disk you don't want to move to external storage, full OS-level control, or it's a large, always-busy workload you run as fixed infrastructure. Sinkron is the cheaper, lower-effort choice for the common case: a container you just want online, reachable, and not babysat. If your app is a specific stack, we have step-by-step guides for Flask, FastAPI, and Node.js too.