Back to Blog

Moving Off Northflank After the Security Incident: A Simple Guide

5 min read
Diagram of services moving from Northflank through Ankra into your own cluster with web, api, worker, postgres and cron
On this page

On 30 October, Northflank disclosed a security incident. It told customers to assume every environment variable on the platform had been decrypted and to rotate all their keys. A few days later it said the attack had focused on secrets held in its control plane, and that some AI API keys had been used without permission. The full timeline and what each platform holds is in Ankra vs Northflank.

Since then, a lot of teams have asked us the same question: how hard is it to leave? For most apps, not very. This post walks through the move the way it actually feels, without the jargon.

Start with your keys, not your apps

Before you move anything, rotate every secret that lived on Northflank. That means database passwords, Stripe and payment keys, cloud credentials, AI provider keys and webhook secrets. Rotate each one with whoever issued it, so the old value stops working everywhere.

It feels like the boring part, but it’s the part that actually protects you. Moving a leaked key to a new platform doesn’t fix the leak. And because you’ll set fresh values on Ankra anyway, there’s nothing to export.

The move, in five steps

Five steps: rotate keys, get a cluster, add your apps, move your data, switch DNS

1. Rotate your keys

Covered above. Do it first.

2. Get a cluster

If you liked that Northflank ran everything for you, use Ankra Cloud. It’s our own cloud, and Ankra runs the cluster for you. The smallest option is a dev cluster: one server, and no control plane fee.

Terminal window
ankra cluster managed create --provider ankracloud_k8s --dev-cluster

If you’d rather stay on AWS, Hetzner, OVHcloud, UpCloud or DigitalOcean, Ankra builds the cluster there instead. And if you used Northflank’s bring your own cloud, you can import the cluster you already have. The first 30 worker vCPUs are free on every plan.

3. Add your apps

From each repository, run one command.

Terminal window
ankra application add .

Ankra looks at the code and opens a pull request with everything it needs to build and run it. If you already have a Dockerfile, it uses yours. You review it like any other pull request and merge it. That’s the setup.

From then on, every push runs tests, builds the image inside your own cluster and scans it for vulnerabilities before anything ships.

Then set your new secrets. They’re sealed into the app and never shown again.

Terminal window
printf '%s' "$NEW_STRIPE_KEY" | ankra application env-secrets set <app> STRIPE_KEY
ankra application env-secrets apply <app>

4. Move your data

Your database moves into your own cluster, run by CloudNativePG, with backups going to a storage bucket you own. Copying the data is a dump from Northflank and a restore on Ankra, in one line.

Terminal window
pg_dump --no-owner "$NORTHFLANK_DATABASE_URL" \
| ankra cluster exec shop-db-1 -n shop -c postgres --stdin -- psql -U postgres -d shop

Do it once as a practice run. You’ll learn how long it takes, and that number is the length of your maintenance window.

5. Switch DNS

Pause your Northflank services, run the final copy of the data, and point your domain at the new cluster. The HTTPS certificate is issued for you. Keep Northflank paused, not deleted, for a few days in case you want to compare anything.

Everything you used has a home

Northflank features mapped to Ankra: cloud to Ankra Cloud, services to Applications and Pipelines, previews to pull request previews, secret groups to sealed app secrets, addons to Postgres in your cluster, microVM sandboxes to a microVM cluster per tenant

Preview environments carry over too. Turn on previews for an app and every pull request gets its own link, posted right on the pull request.

Running untrusted code? Give it its own microVM

Some teams chose Northflank because they run code they didn’t write: AI agents, customer scripts, one environment per customer.

On Ankra Cloud, every server is a KVM microVM run by Cloud Hypervisor. A dev cluster is a whole Kubernetes cluster inside one of them, starting at 1 core and 1 GiB. Give each customer or sandbox its own small cluster and it gets its own kernel, its own API and its own network. If something breaks out of a container, it’s still stuck in a VM with nothing else in it.

Three microVMs on one Ankra Cloud server, each running single-node Kubernetes for Tenant A, Tenant B and an AI sandbox

Clusters are quick to create and delete, so you can make one per job and throw it away when the job is done.

What day two feels like

Once you’ve moved, things get quieter. You push code, and a pull request shows the test results, the security scan and a preview link. Merging ships it to development. Promoting to production is a button, and it ships the exact image you tested.

When a build fails, Ankra’s AI looks at why and often opens the fix as a pull request. When an alert fires, it arrives with an explanation of what changed. Nothing the AI wants to change happens until a person says yes.

And your secrets stay where they belong. Your apps run in your own cluster. Ankra’s view of that cluster keeps only fingerprints of your secrets, never the values, and the AI never sees them.

One honest caveat

If you leaned on Northflank’s managed database addons and don’t want to run a database operator yourself, know that Ankra’s own managed databases are still in closed beta. CloudNativePG covers Postgres well today, and we’re happy to help you set it up.

Ready to move?

Pick one service, the smallest one, and move it first. Create a free account and run ankra application add . in its repository. Most teams know within a day whether the rest should follow, and if you get stuck, talk to us.

ShareXLinkedInHN

Get the next post in your inbox

Platform engineering guides and product updates. No spam, unsubscribe anytime.

Related Posts