Northflank Security Incident (October 30, 2026): What Happened and How to Protect Your Secrets

Key Points:

• What happened. On October 30, 2026, Northflank reported a security incident. Its status page tells every user to "assume all environment variables have been decrypted" and to rotate all secrets. Users report that their AI keys were already used.
• What is not known yet. As of the 19:28 UTC update, Northflank has not published a root cause or a list of affected customers. The page does not say whether Bring Your Own Cloud (BYOC) customers are affected.
• What to do today. If you use Northflank, rotate AI and payment keys first, then database and cloud credentials, then the rest. Check provider usage logs for the days before the incident.
• Why this keeps happening. Northflank is the second deployment platform in nine days to lose customer secrets, after Railway on October 21. A shared platform stores the secrets of all its customers in one place, so one break-in pays off many times.
• What we learn at Qovery. This can happen to any platform, including ours. Qovery is not a PaaS and does not host customer apps. Your apps run in your own cloud account, Qovery reaches it through an IAM role you can delete, and secret values can stay in your own secret manager. Qovery still stores the secrets you add in the Console, encrypted, and this article says so plainly.

First, to the Northflank team: we are sorry this happened to you, and we wish you a fast recovery. Northflank competes with Qovery, and we would never wish this on anyone. A security incident can happen to any company, including ours. The engineers working on it today have a hard few days ahead, and we hope their customers are safe again soon.

I am writing this because many teams who use Northflank are asking what to do this week, and because the same question applies to every deployment platform, ours included: if the platform is hacked, what can the attacker read?

This article sticks to what Northflank and its users have said in public. When something is not known, I say so.

What happened at Northflank on October 30, 2026?

Northflank's status page lists a "Security incident" marked as a major outage. Here is the timeline it gives, in UTC:

Northflank's advice covers secrets in workloads, secret groups and global secrets. It also asks users to turn off public access on addons (Northflank's managed databases and services) where it is enabled.

The incident reached the front page of Hacker News the same afternoon. One user wrote that a small app on Northflank now needed new RevenueCat, Apple and AI keys. Another listed six attacks on hosted platforms since September, including Railway.

What we don't know yet

• The root cause. Northflank has not said how the attacker got in. The timeline shows network policy patches, which suggests a network path inside the platform was closed, but Northflank has not confirmed what that path was.
• Who is affected. The guidance is written for all users. There is no list of affected projects or regions.
• BYOC customers. Northflank sells a BYOC option where workloads run in the customer's cloud account. Its BYOC page says "workloads, databases, volumes, and secrets run inside your VPC." The status page does not separate BYOC users from the others. If you run Northflank BYOC, ask Northflank directly, and rotate anyway until they answer.

We will update this article when Northflank publishes more.

What should you rotate first?

Rotate the secrets an attacker can turn into money or access fastest. The order below is the one we used in our Railway rotation guide, which has the full step-by-step checklist.

1. AI provider keys (OpenAI, Anthropic, and others). Northflank users already report misuse. Revoke the old key, create a new one, and set a spending limit on it.
2. Payment and billing keys (Stripe, RevenueCat, App Store Connect). Stripe can keep the old and new keys working together for a short time, so you can deploy the new key before you revoke the old one.
3. Cloud credentials (AWS access keys, GCP service account keys). Replace long-lived keys with IAM roles where you can.
4. Database passwords. Northflank enabled rotation for its Postgres and MongoDB addons. For external databases, create a second user, deploy it, then delete the first.
5. Session and JWT signing keys. Changing them logs every user out, so plan the timing.
6. OAuth client secrets, webhook secrets, Git tokens and registry credentials.

For each key, follow the same four steps: create the new one, deploy it, check that the app works, then revoke the old one. Revoking first is the fastest way to cause your own outage.

When you are done, check the provider side. Look at usage and billing for each rotated key over the last few days. Look for new API keys, users, SSH keys, OAuth apps or webhooks that you did not create. An attacker who had your keys may have used them to create new ones.

Why do deployment platforms keep losing customer secrets?

A deployment platform has to give your app its secrets. So at some point it stores them, decrypts them, or both. When the platform is shared by many customers, the store holds the secrets of all of them.

That makes a deployment platform a good target. One way in gives the attacker database passwords, cloud keys and AI keys for many companies at once. AI keys are the easiest to use right away, which matches what Northflank users report.

A Hacker News commenter described a second problem. Platforms usually let users read a variable back in the dashboard or the CLI. If a platform can show you a secret, then anyone who takes over the platform's API, or a user's session, can read it too.

Encryption at rest does not solve this. Railway's preliminary report says its variables were encrypted, and some were decrypted anyway. Something has to decrypt a secret to deploy your app, and that something can be attacked.

How does Qovery limit the damage of a breach like this?

Qovery deploys code too, and nothing in this section means it could not happen to us. The honest answer has two parts: what we do not hold, and what we still hold.

Qovery does not host your apps, and never will

Northflank and Railway are managed PaaS products: they run their customers' apps on infrastructure they operate. Qovery does not, and we never will. We built Qovery from day one around one rule: the control plane (Qovery) is separate from the data plane (your cloud account).

Qovery installs and manages a Kubernetes cluster in your own AWS, GCP, Azure or Scaleway account, or connects to a cluster you already run. Your apps, databases, logs and TLS keys run and stay there. There is no Qovery-run fleet of servers where customer apps sit next to each other, so there is no shared runtime for an attacker to move through, and another customer's code never runs in your cluster.

Qovery's control plane sends deployment instructions to the Qovery engine over encrypted gRPC or TLS. It holds your configuration and status, and the secrets you choose to store in Qovery. The security overview describes this split in detail.

Secret values can stay in your secret manager

With the Secret Manager integration, you give Qovery a reference such as prod/payments/stripe instead of the value. The External Secrets Operator, running in your cluster, reads the value from AWS Secrets Manager, AWS Parameter Store or GCP Secret Manager and passes it to your app. The value never goes through Qovery. If Qovery's control plane were breached, the attacker would find the path to your secret but not the secret itself.

Two limits to know. This integration is available today on Qovery-managed clusters on AWS and GCP. And the operator reads the values at deploy time, so after you rotate a secret you redeploy the services that use it. For the most sensitive secrets, your app can also read them at runtime with an IAM role, which needs no redeploy. Our article on how Qovery stores secrets shows both setups.

Qovery reaches your cloud through a role you control

On AWS, Qovery recommends the STS assume role setup. Qovery gets short-lived credentials from an IAM role in your account, instead of storing a permanent access key. Since October 23, the role also requires your organization ID as the sts:ExternalId, so it only accepts requests made for your organization (details). On GCP, Workload Identity Federation works the same way.

If you ever lose trust in Qovery, you delete the role. Qovery loses access to your account in one step, and your apps keep running in your cluster.

What Qovery still holds

Secrets you add in the Qovery Console, without a secret manager, are stored in Qovery's database. They are encrypted with AES-256 and a key unique to your organization, hidden in the Console, and cannot be read back through the API. They are decrypted when a deployment needs them.

Write-only secrets close the read-back path described above, because no screen or API call shows the value. They do not close every path. An attacker with deep enough access to our control plane could reach what the deployment process decrypts. That is why, after the Railway and Northflank incidents, I recommend keeping production secrets in your own secret manager and giving Qovery only the references.

I have always told my team that this can happen to anyone, and a breach like this is one of my biggest fears at Qovery. That is why we have invested in security since the first days of the company. It is a large part of our budget, and we will keep investing in it.

Qovery is SOC 2 Type II certified, and independent experts run a penetration test every year with one main goal: stealing customer secrets. Reports are on our trust center. We do our best to keep our customers safe, and none of that makes a breach impossible. It is why we would rather you hold the values yourself.

Questions to ask any deployment platform this week

Use these with Qovery, Northflank, Railway or any other vendor.

To the Northflank team and its users: we hope you are back to normal soon.