Build a Golang App in 10 Seconds Using BuildKit

No joke. From pushing your code to seeing it running in your browser. Around 10 to 20 seconds depending on your app size.

If you've ever waited forever for Docker builds or CI/CD pipelines, you need to see this.

What is BuildKit?

BuildKit is basically Docker builds on steroids. It's what powers modern Docker builds, but way more powerful when you use it directly.

The key features that make it insanely fast:

• Aggressive caching: It remembers everything and only rebuilds what actually changed
• Parallel builds: Multiple layers build at the same time instead of waiting in line
• gRPC communication: Super efficient communication protocol
• Scales horizontally: Need more speed? Just add more BuildKit pods

In our beta program, BuildKit is automatically deployed as a daemon pod that's always running and ready to build your stuff.

How it works on RunOS

We've set up the entire flow to be stupidly simple. Here's what happens automatically when you join the beta:

Everything talks to everything else automatically. You don't configure any of this.

Test it right now with sample apps

Want to see how fast this really is? We've got ready to go example apps you can clone and deploy immediately.

RunOS provides sample repos for different languages:

Clone any of these and you can deploy in literally 30 seconds. No modifications needed. They already have Dockerfiles configured correctly.

Deploying your first app

Here's literally all you do (or watch the full video walkthrough):

1. Clone a sample repo (or use your own)

For this example, let's use the Golang sample:

git clone https://github.com/runos-official/public-test-runos-golang-deploy.git
cd public-test-runos-golang-deploy

If you're using your own app, just make sure you have a Dockerfile in the root. Basic example:

FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

FROM alpine:latest
COPY --from=builder /app/main /main
EXPOSE 3000
CMD ["/main"]

2. Add the Gitea remote

You'll get a git URL from your RunOS dashboard. Add it as a remote:

git remote add runos https://username@gitea-url/username/myapp.git

No need to create a repo on Gitea. It auto creates repos when you push. You literally never have to log into Gitea if you don't want to.

3. Push your code

git push runos main

That's it. Watch the magic happen.

What happens next

The moment your code hits Gitea:

• BuildKit detects the push
• Finds your Dockerfile
• Starts building (with all that aggressive caching)
• Pushes the built image to Harbor
• Deployment references the Harbor image
• Your app starts running

From push to running: usually under 20 seconds for a basic Go app. First build might take a bit longer, but subsequent builds? Insanely fast because of the caching.

Multiple environments

This is where it gets really cool. Want separate dev, staging, and production environments?

Certain branches automatically trigger deployments:

• main and master branches auto deploy
• Any branch starting with deploy- also auto deploys

So you can do this:

git checkout -b deploy-dev
git push runos deploy-dev

git checkout -b deploy-staging
git push runos deploy-staging

Each branch automatically becomes its own deployment with its own HTTPS subdomain. You can test different versions in parallel. No config files. No YAML. Just push and it's live. All with automatic HTTPS certificates.

Environment variables and secrets

Obviously you need to configure stuff like database URLs, API keys, whatever.

Don't put that in your code (seriously don't). Add environment variables through the RunOS dashboard for your app.

Anything you mark as sensitive goes into Kubernetes secrets that are encrypted. You can't view them unless you have the decryption key. So your API keys and database passwords stay safe.

Ports and URLs

By default, RunOS expects your app to run on port 3000. That's what gets exposed automatically.

Need a different port? Just expose it in your Dockerfile:

EXPOSE 8080

Then configure it in the app management section. Each port you expose gets its own URL. So if you expose ports 3000 and 8080, you get two separate URLs to access different parts of your app.

Adding services

Need a database? Redis? Message queue?

Go to the RunOS services section, click to install whatever you need. PostgreSQL, Redis, Kafka, whatever. It's up in seconds.

Each service gets an internal URL that you can find in the service management page. Add that URL to your app's environment variables. Your app can now talk to the service.

Example: Install PostgreSQL, grab the internal URL from the service management page (something like postgresql://postgres:5432), add it as DATABASE_URL in your app, reference it in your Go code. Done.

Scaling BuildKit

If builds are taking too long (maybe you have a huge app or lots of dependencies), you can scale up.

More resources: Give BuildKit more CPU and memory

More pods: Scale out to multiple BuildKit pods running in parallel

More nodes: Add more cluster nodes and pods distribute automatically

This means you can push multiple apps at the same time and they all build in parallel. Or if you have a team pushing code constantly, everyone's builds happen fast.

Custom services

What if you need something that's not in our services list?

You can install any Kubernetes deployment, Helm chart, or operator yourself. It's a real Kubernetes cluster, just way easier to use.

Find what you need, install it, configure it how you want.

And hey, if you think something should be in our services list, tell us. We're always adding stuff people actually use.

Try it yourself

The best way to understand how fast this is: just try it.

Our beta program gives you everything set up and ready. BuildKit, Gitea, Harbor, the whole stack. You just push code and watch it deploy.

Start with one of our sample repos. Clone it, push it, watch it build and deploy in under 30 seconds. Then try your own app. Need help getting started? Watch our complete walkthrough video.

Build something. Break something. See how fast you can iterate.

Why this matters

Fast builds mean you iterate faster. You try things. You experiment. You're not sitting around waiting for CI/CD.

And when you can spin up new environments with just a branch push? You test more. You break less in production.

This is how development should feel. Fast. Simple. No waiting around.

Let's make slow builds a thing of the past.