Why We Built FluxNow

It was a Tuesday night. A side project we actually cared about was breaking in production, and the stack trace pointed at a migration that had run against the wrong database. Again.

We'd been here before. Different project, different year, different cloud bill, same story. Something was wrong with the way we — and almost every backend team we'd ever worked with — were shipping code.

So we decided to stop. We weren't going to ship another app until the scaffolding underneath it felt as good as the frameworks on top of it. That decision turned into FluxNow.

The thing we kept rebuilding

Every serious backend project has the same hidden boilerplate. A registry. A way to build images on push. A secrets store that isn't a .env file in a private Slack. A staging environment. A way to run a migration before the new pod starts serving traffic. A way to give your teammates a URL for the branch they're working on, so product can click around before the PR is merged.

None of this is novel. All of it is work. We kept doing it for every project — copy the GitHub Actions workflows, wire up the Helm chart, configure ArgoCD, set up the CNPG cluster, remember which database was which — and every time we finished, the project was a month older than it should have been.

The most painful part was the feedback loop on databases. If your PR touched a schema, the only way to really know it worked was to run it somewhere. And the only somewhere you had was staging. One shared staging database, where every teammate's branch migration fought every other teammate's branch migration, and half the failures in review were actually failures from last week that nobody had rolled back.

We didn't want a better dashboard for this. We wanted the problem to go away.

What we actually wanted

Write a list with us.

We wanted git push to be the whole deploy workflow. Not git push plus a dashboard click plus a Slack bot DM plus a reminder to bump an image tag.

We wanted every PR to get its own URL and its own database, branched from staging in a couple of seconds, destroyed automatically when the PR closed. Not staged. Not shared. Yours.

We wanted migrations to run in the same way on every environment, without us writing a separate Helm hook for each framework, without a shaky startup.sh that sometimes runs them and sometimes doesn't. A release line in fluxnow.yaml. One line. Everywhere.

We wanted the preview URL to be in the PR comment. We wanted the real latency number to be there too. If staging was down, we wanted to see it without opening Grafana.

And underneath all of that, we wanted to actually own our stack. Not rent it. We wanted bare metal we could SSH into when Kubernetes lied to us. We wanted a registry that wasn't going to invoice us per pull. We wanted a vault we could rotate tokens on without filing a support ticket.

We looked around first

Engineers are supposed to be lazy. Before we built anything we tried everything else. Vercel is beautiful for frontends but it's not where your Postgres lives. Railway is the closest philosophical cousin, and we love what they do, but the billing model gets sharp on small teams and the database story is conventional. Render is solid. Heroku is frozen. Fly.io is fantastic for compute but leaves you to assemble the data plane. Coolify is doing great open-source work, and we learned a lot from reading it.

None of them gave us the one thing we wanted most: a database that branches when the code branches, automatically, with no SaaS lock-in, on infrastructure we controlled. So we wrote the smallest thing that could possibly work, on top of tools we trusted.

The stack (and why this stack)

FluxNow runs on bare-metal Hetzner servers in Helsinki, virtualized with Proxmox, scheduled by Talos Kubernetes and Nomad. Customer apps run on Kubernetes. Sandbox workloads run on Nomad microVMs. PostgreSQL 18 is operated by CNPG, and preview databases are FILE_COPY clones of staging — a PG18 feature that gives us sub-second branch creation without a separate branching layer. Harbor is the registry. OpenBao (a fork of Vault) is the secrets store. ArgoCD does the GitOps. VictoriaMetrics eats the logs and metrics and traces.

We didn't pick any of this because it was trendy. We picked it because each piece was the boringest thing that did its job, and because nothing in the pile asked us to trust a closed-source SaaS with our data.

None of our customers ever has to know any of this exists.

That's the whole point.

The thing we care about most

If FluxNow has a single opinion, it is this: the database should branch when the code branches.

Open a PR and you get a URL. You also get a Postgres database — your own, forked from staging in the time it takes to pour a coffee, populated with a recent copy of your staging data, destroyed when you close the PR. Your migrations run against it on every push. Your preview app connects to it automatically. Your teammates can point their local laptop at it to reproduce a bug without asking anyone for access.

This is the feature we wanted most, for the longest time, across every project we've ever shipped. It's the one that makes the rest of the platform feel obvious in hindsight.

We built this for us

FluxNow exists because we wanted to enjoy backend work again. We wanted to ship a side project in an evening without paying a tax in YAML. We wanted to feel, on Monday morning, that the infrastructure underneath our code was on our side.

Everything we've built, we run ourselves. The dashboard you sign into at fluxnow.app is deployed by FluxNow. The marketing site you're reading this post on is deployed by FluxNow. The onboarding service that provisions your preview database is deployed by FluxNow. When something breaks, it breaks for us first, and we fix it before you ever see it.

We're not going to tell you the future is AI agents deploying apps for you (although we're building for that too). We're not going to tell you deployment is a solved problem (it isn't). We're going to tell you what's honestly true: we built a platform that we enjoy using, on a stack we understand, with an opinion we believe in, and we'd love for you to try it.

Push code, not buttons. Branch your database. Preview your future.

That's the pitch. The rest is implementation detail, and we're going to keep writing about it here.

Install FluxNow on one of your repos. Open a PR. Watch a database appear for it. Tell us what you'd change.

We built this because we wanted it to exist. We kept it simple because we're the ones who have to run it on call. We're sharing it because good tools compound when other engineers use them — and because writing code that ships cleanly is one of the best feelings in this job, and we'd like more of it in the world.

— The FluxNow team