Deploy From Your Laptop With Nothing Installed

Here’s a deploy flow most platforms can’t do: you have a folder of code on your laptop, no Docker installed, no git remote configured, no registry account anywhere. You run one command and a few moments later your app is live on HTTPS.

runos deploy

That’s the whole thing. This post is about what happens underneath, because the underneath is the interesting part.

Your laptop does almost nothing

You bring two files alongside your code: a Dockerfile that says how to build it, and a runos.yaml that says how to run it. What you don’t bring is any of the machinery that usually executes them.

When you run runos deploy, the CLI tars up your source, asks the platform for a single-use upload token, and sends the archive straight to your cluster. That’s it. Your machine never builds an image, never talks to a registry, and never runs a Docker daemon.

The build happens where the compute is: on your own cluster.

Ephemeral builders, not a build daemon

There is no build server sitting around waiting for work. For every build, RunOS spins up a fresh BuildKit pod, builds your image, pushes it to the Harbor registry running in your cluster, and tears the pod down.

Every build starts from a clean room. Layer cache lives in the registry, so second builds are fast without keeping a warm daemon around.

This has a security payoff too. Build secrets, like an SSH key for a private dependency, are streamed into the build as BuildKit mounts. They never land in image layers, pod specs, or the registry. When the builder pod dies, they’re gone.

The git path, when you want it

Deploying from local files is great for getting something live. For a team, you’ll want deploys keyed to commits, and RunOS does that too: connect GitHub or GitLab and every deploy is pinned to a full commit SHA.

Images are tagged by that SHA, which makes builds idempotent. Push the same commit twice and the second deploy short-circuits: the image already exists, so it rolls out in seconds. RunOS even generates the CI workflow file for you with runos apps ci-file.

Migrations that gate the rollout

On the git path, deploy has a sibling: run. It reuses the image for a commit and executes a one-shot job with your app’s environment injected:

runos run --app <app> --sha <sha> --follow -- bin/rails db:migrate

With --follow, the command carries the job’s real exit code, so a failing migration fails your pipeline. Your migration failing means your deploy doesn’t happen, which is exactly the order you want those two things in.

The honest bits

First builds are the slow ones, usually tens of seconds depending on your app, because the cache is cold. After that, the registry-backed layer cache kicks in and rebuilds get quick. And builds run on your cluster, so they use your resources: a tiny single-node cluster building a heavy app will feel it.

Try the fastest path from folder to production you’ve used.

Start free and see the deploy docs for all six deploy methods.