Who Is a True BYOC PaaS, and How Do They Actually Work

Intro

Friends and family, its me again. Today I want to talk about an area of engineering I am curious about. This area is BYOC which means Bring Your Own Cloud. BYOC has quietly become one of the most overloaded terms in platform engineering. Ask ten vendors what it means and you will get ten answers, and a few of those will flatly contradict each other. So before I get into who I think is doing this differently from the other and how the machinery holds together, I want to be upfront about two things:

1. This is my read on it, not a spec. It's simply what Joojo thinks. A lot of what follows came together while I was researching the space, and I leaned heavily on material from Northflank, Render and a handful of other vendors and write-ups along the way. Where I've landed on a definition or drawn a line, that is me synthesising what I found and forming a view, so treat it as one engineer's mental model rather than the final word.

2. Here is the working definition. BYOC, or bring your own cloud, is a deployment (and sometimes reconciliation) model where a vendor's control plane manages and runs software inside the customer's own cloud account, so the workload and its data stay on the customer's infrastructure and bill, while the vendor operates the experience from outside. That is the whole idea in a single sentence.

What BYOC might not be

I find it easier to pin down BYOC by ruling things out first, because the marketing pages have stretched the term so far that the cleanest way in is through the back door. So here are three things that, to my mind, quietly disqualify a vendor from the true version of this, even when the website says otherwise.

1. If the vendor's product can see your data, it is not BYOC. This is the big one. The moment your data passes through the vendor's systems, or sits somewhere they can read it, the whole premise has already broken. It does not matter that the workloads happen to run in your account if the bytes are still visible on their side of the fence.

2. If the vendor terminates your requests before they reach your VPC, it is not BYOC. Picture traffic hitting the vendor's load balancer or gateway first, getting processed there, and only then being forwarded into your network. That front door belongs to them, not you, and anything that lands on it has left your boundary before your account ever sees it.

3. If the infra costs are billed to the vendor and then the vendor bills you, it is not BYOC. The whole point is that your cloud provider invoices you directly for the compute and storage your workloads consume. The second that spend gets routed through the vendor and rebilled to you, they are back to being a middleman reselling infra, which is the exact arrangement BYOC is meant to get you out of.

The request-path one is the easiest to picture:

TRUE BYOC      user ──► your VPC ──► your workload
               (vendor never sits in the path)

NOT BYOC       user ──► vendor gateway ──► your VPC
                              ▲
                        terminated here,
                        outside your boundary

Now the important caveat. None of these three are bad in and of themselves. Plenty of excellent products see your data, terminate your requests, or resell infra, and for a lot of use cases that is completely fine and often the better choice. I am not knocking any of it. The point is narrower than that: in the true essence of BYOC, none of these things are happening, and if one of them is, you are looking at something else wearing the BYOC label.

The two halves: control plane and data plane

Everything in a BYOC setup sits on one side of a line, and the line is drawn by a single question: who can see it, and whose cloud is it running in. That split has a name in two parts, the control plane and the data plane, and getting clear on which is which is the thing that makes the rest of this article make sense.

        VENDOR SIDE                                YOUR CLOUD
  ┌───────────────────────┐                ┌───────────────────────┐
  │   CONTROL PLANE        │                │   DATA PLANE           │
  │   • UI                 │   permission   │   • nodes / workloads  │
  │   • APIs               │   grants       │   • secrets            │
  │   • observability      │  ───────────►  │   • application code   │
  │                        │                │   • databases          │
  └───────────────────────┘                └───────────────────────┘
                                  ▲
                          network boundary
                    (your data never crosses it)

• The control plane stays with the vendor. Think of it as the brain and the dashboard rather than the workload itself. It is usually some combination of three things: the UI you log into, the APIs you call to tell the platform what you want, and the observability layer that shows you what is happening. None of this touches your actual data. It is the experience of operating the platform, and it lives on the vendor's side because that is the thing you are paying them to run well.

• The data plane stays with you, inside your own account. This is where your real stuff lives: the nodes your workloads run on, the secrets they depend on, your application code, the databases, all of it. Everything that actually processes or holds your data sits here, behind your network boundary, billed to you directly. The vendor can orchestrate it and reconcile it, but in the true version of this they are working through permissions you granted rather than reaching into a box they own.

The way I find it useful to think about it is as two questions, not one. Who operates the control plane, the vendor or you? And whose cloud is the data plane running in, theirs or yours? Plot those two against each other and you get a map that tells you very quickly whether something deserves the BYOC label at all.

                       CONTROL PLANE: VENDOR
                               ▲
   data plane in VENDOR cloud  │  data plane in YOUR cloud
   ┌───────────────────────────┼───────────────────────────┐
   │  MANAGED SaaS / PaaS       │  TRUE BYOC                 │
   │  Heroku, Render,           │  Northflank, Porter,       │
   │  Vercel, Fly.io            │  Qovery, Flightcontrol     │
   ├───────────────────────────┼───────────────────────────┤
   │  ~ empty                   │  SELF-HOSTED / DIY         │
   │  (run the brain AND        │  EKS Anywhere, GKE         │
   │   rent the data plane?)    │  Enterprise, OpenShift     │
   └───────────────────────────┼───────────────────────────┘
                               ▼
                       CONTROL PLANE: YOU

• Top-right is true BYOC. The vendor operates the control plane, so you get the managed experience, but the data plane runs in your cloud. That is the combination the whole model is built around. Northflank, Porter, Qovery and Flightcontrol live here, alongside the orchestrators like Humanitec and Massdriver that provision but do not run your workloads. And this is the corner where my disqualifiers from the last section bite hardest. It is only genuinely BYOC if the control plane stays out of the request path and never sees your payloads. The moment it does, the thing has quietly slid out of this corner.

• Top-left is managed SaaS and PaaS. The vendor runs the control plane and the data plane lives in their cloud too. That is Heroku, Render, Vercel, Fly.io, the default tiers of things like Railway. Excellent products, just not BYOC, because your data never left their side.

• Bottom-right is self-hosted and DIY. You run both the control plane and the data plane yourself: EKS Anywhere, GKE Enterprise, OpenShift, self-hosted Crossplane, Terraform and Pulumi run on your own.

• Bottom-left is almost always empty, for a reason worth sitting with: if you are already operating the control plane yourself, you would just host the data plane too. Renting the vendor's data plane while running your own brain drags their trust boundary right back in, which defeats the entire point of going BYOC in the first place.

One thing to watch for, because vendors do it. Single-tenant SaaS running in the vendor's own cloud sometimes gets marketed as BYOC. On this map it really lives top-left. The data plane is still in their account, no matter what the pricing page calls it.

The two axes that actually define a BYOC product

Here is where it gets interesting, and where I want to be careful with a word. Earlier I used "plane" for the control plane and data plane, the split of who sees what. This next idea is different, so I am going to call these two things axes rather than planes, to keep them apart in your head. These are the two decisions that, more than anything on a pricing page, determine what a BYOC product actually is, and knowing them helps you read any vendor more clearly.

                         RECONCILED
              (vendor holds it to spec, fixes drift)
                             ▲
   PORTABLE                  │                  NATIVE
   one contract,             │             expose each
   many clouds               │             cloud's own knobs
   ◄─────────────────────────┼─────────────────────────►
   point at a generic        │             point at an
   external interface        │             external truth
   (sparse)                  │             (secret value, org IAM)
                             ▼
                         REFERENCED
            (someone else owns the spec, you adapt)

Axis one: how abstract is the contract

The first axis is the level of abstraction in the contract the platform hands you. This looks like a UX question and it is not. Where a vendor draws the portable-versus-native line is their build surface, their test matrix, their support load and their release cadence all at once. It is an engineering and economics decision wearing a UX costume, and it shapes what you can actually do with the product.

At one end sits the portable contract. It abstracts away the native knobs and maps the same spec across different products in different clouds:

• service becomes Cloud Run on GCP, ECS on AWS, or Container Apps on Azure
• job maps to Cloud Run Jobs, AWS Batch, or ACA Jobs
• identity becomes a service-account binding, an IAM role, or a managed identity, depending on where it lands

A portable service spec looks roughly like this:

{
  "service": "checkout-api",
  "image": "registry/checkout:1.4.2",
  "cpu": "1",
  "memory": "2Gi",
  "port": 8080,
  "scaling": { "min": 1, "max": 10 }
}

Nothing in there names a cloud. The vendor takes that and translates it into whatever the target provider needs. One contract, three backends.

At the other end sits the native contract, also called native passthrough. Here the spec includes attributes that only exist on one specific cloud. As a power user you might want exactly a Lambda function with 3008 MB of memory and a ten-minute timeout, or exactly a Cloud Run service with a minimum instance count of one, and you do not want the vendor abstracting that away. So the platform lets you write it straight through:

{
  "service": "checkout-api",
  "image": "registry/checkout:1.4.2",
  "aws": {
    "lambda": {
      "memoryMB": 3008,
      "timeoutSeconds": 600,
      "architectures": ["arm64"]
    }
  }
}

That is great when you know the AWS playbook and want the vendor out of the way. But it can go south fast, and this is the part worth sitting with. If a vendor's headline promise is portability, the instant you set a native AWS parameter, that workload stops being portable. The one-contract-across-clouds promise silently dies for that resource. The product is now really two experiences in one: a portable lane that moves between clouds, and a native lane that does not, and you can wander from one into the other without ever realising you just gave up portability. So when you read "works across any cloud" on a landing page, the question to ask is what happens the moment you reach for a cloud-specific knob.

Axis two: who owns the source of truth

The second axis is ownership of the reconciliation source of truth, and this is where most of the real value sits, because it is hard to build and hard to leave. When a vendor gets it right it is a genuine moat, which also means it is the thing you most want to understand before you commit.

• The vendor owns the spec and enforces it (reconciled). You tell the vendor what you want, the vendor provisions it, and then the vendor keeps it that way. The onus is on them to hold the resource to the spec, possibly reconciling forever, correcting drift every time reality wanders away from what you asked for.

• Someone else owns the spec and the vendor adapts (referenced). Here the vendor does not hold the spec at all. It either does not exist on their side, or somebody else owns it. A secret value is the cleanest example. The vendor cannot reconcile the value of a secret, because the spec for that value, the rotation policy, lives with you or an external rotation system. What the vendor can reconcile is the grant, the permission a given resource has to read that secret. When the secret rotates, the reconciliation either adapts because the authenticating resource is told about the change, or it breaks. The vendor is pointing at a truth they do not control and adapting to it, rather than enforcing a truth they own.

The quadrant, and why it is a product-shape question

Put those two axes against each other and you get a quadrant. This is the management map, and the important move is realising it is not only a per-resource decision. It is a product-shape decision. Asking which quadrants a vendor operates in at all tells you what kind of business they are, not just how they handle one resource.

And a vendor can absolutely build a real business in the half that provisions without reconciling. That is exactly what one-shot IaC generators and setup wizards are. Pulumi and Terraform Cloud largely live there: they apply a spec, and between applies they do not hold your infrastructure to it unless you go out of your way to wire up continuous drift detection. Provisioning once and reconciling forever are different products with different cost structures. The reason this matters to you as the person choosing is simple: it is easy to assume a tool will keep your infrastructure in the state you asked for, when all it really promised was to set it up once and walk away.

Who is actually doing this

So who passes the test? Here are the players I kept coming back to during my research, with the caveat that this is a fast-moving space and the lines move, so check the pricing pages before you commit to anything.

The true players

• Northflank is the one with the broadest coverage and the easiest on-ramp. It runs across six providers at last count, AWS, GCP, Azure, Oracle, CoreWeave and Civo, plus on-premises and bare metal, and it is self-serve, so you can get going without a sales call. If you want the full deployment lifecycle in your own cloud, CI/CD, managed databases, preview environments, GPU workloads, this is the one that tries to cover all of it in one place.

• Porter takes a different shape. It deploys a Kubernetes-based platform into your AWS, GCP or Azure account and gives you a Heroku-like experience on top, so you get the managed feel without having to operate Kubernetes yourself. One number worth knowing going in: because every cluster carries the EKS control plane overhead, there is roughly a $225 a month floor on AWS before you have deployed anything meaningful. That is not a knock, it is just the shape of the bill, and it tells you Porter is aimed at teams past the hobby stage.

• Flightcontrol is the narrow, opinionated one. It is AWS only, it runs on ECS rather than Kubernetes, and it leans on standard AWS primitives like CloudFormation and IAM role assumption. If you are all-in on AWS and you do not want Kubernetes anywhere near your stack, the narrowness is the feature, not a limitation.

The three buckets that get called BYOC but are not quite

Then there is everyone else who gets called BYOC but is really doing something adjacent. I found it useful to split them into three buckets, because each one is a perfectly good tool that simply answers a different question.

1. Portal and orchestrator only (Backstage, Port, Cortex). These are developer portals and catalogues, the front door to your platform, but they have no data plane of their own. They point at infrastructure that already exists, they do not stand it up in your cloud, so plotting them on a BYOC map does not really work. They are solving the discovery and self-service problem, not the run-it-in-your-account problem.

2. Data-service BYOC (Aiven is the clearest example). Here the BYOC idea is real but scoped tightly to data infrastructure: managed databases and streaming, Kafka, ClickHouse and friends, running inside your own VPC. If your whole reason for wanting BYOC is keeping the database in your account, this is the specialist lane, but do not expect it to deploy your application tier.

3. Hyperscaler-managed (EKS Anywhere, GKE Enterprise, formerly Anthos, and AKS Arc). These give you a managed Kubernetes control plane that can run on your own infrastructure, which sounds like BYOC and in a narrow sense is. The catch is that you take on the operational load yourself. You get the Kubernetes plumbing without the PaaS experience sitting on top, so the developer-facing comfort that drew people to BYOC in the first place is the part you now have to build or do without.

The reason I bother separating these is not to crown winners. It is that "BYOC" on a landing page tells you almost nothing until you ask two questions: does it actually stand the workload up in my account, and does it give me a managed experience while doing so. The true players answer yes to both. The three buckets each say no to one of them, and which one they say no to tells you exactly what you are getting.

Why anyone signs up for this

BYOC is not free. You take on real operational weight, so the only sane reason to do it is a specific problem it solves better than the alternatives. Three keep coming up.

Committed cloud spend

This is the one your CFO raises: why pay a SaaS markup for compute when you have already prepaid for hyperscaler capacity sitting unused?

The big committed-spend contracts are why it bites. On AWS, the Enterprise Discount Program, now folded under the Private Pricing Agreement label, is a negotiated contract where you commit to spending a set amount over one to three years in exchange for discounts, usually starting around a million dollars a year. The catch is that the commitment is a floor, not a target. Commit to three million and consume 2.4, and you owe the 600,000 difference at year end regardless. So when a normal PaaS offers to run your workloads at their markup, billed on top of everything you already owe AWS, the question writes itself. BYOC keeps the workloads in the account you are already committed to and charges you only for orchestration, not compute. The prepaid dollars get used instead of forfeited.

Data residency and compliance

The cheapest way to satisfy a residency rule is to put the data plane in the required region and prove the bytes never left, which BYOC does almost by definition.

The pressure is real. Cumulative GDPR fines since 2018 now sit north of seven billion euros, with about 1.2 billion of that in 2025 alone. And the fines are not even the sharp end: companies appeal the headline number but almost always implement the corrective orders, like Meta having to localise its EU data processing. The Gulf has moved fast too, with Saudi Arabia now actively enforcing rules that require sensitive and personal data to stay inside the Kingdom unless a specific exemption is granted. For regulated tenants, healthcare especially, this is the clincher. "Trust us, it is safe on our servers" does not fly with a hospital's compliance team. "Your data never leaves your own account, here is the boundary proving it" does.

Reserved GPUs

The newest driver, and to my eye the fastest-growing. Teams reserve H100s or B200s on long commitments, then need a real platform pointed at hardware they already own. The economics reward BYOC hard: an idle H100 burns three to eight thousand dollars a month, and average GPU utilisation across 23,000 enterprise Kubernetes clusters measured in 2026 was about five percent. Renting a second GPU fleet from a PaaS on top of your reservation makes no sense. You want a platform that points at the capacity you hold and helps you actually use it.

The one-sentence test

BYOC is operational complexity traded for a specific benefit:

• Committed spend you would otherwise forfeit
• A residency rule you must satisfy
• A reservation you need to use

If you can name your benefit in one clean sentence like those, you probably have a real case. If you cannot, and you are reaching for BYOC because it sounds more serious than a normal PaaS, you are about to make your life a thousand times harder for nothing.

The business, and why it is a different animal

The technical model has a financial shadow, and it is worth understanding because it explains why BYOC vendors behave differently from the PaaS you are used to. The short version: BYOC quietly removes the main way platform companies have always made money, and forces them to make it somewhere else.

Dimension	Normal PaaS	True BYOC
Who bills the compute	The vendor, resold to you	Your cloud provider, directly
Where the margin comes from	30 to 50% markup on compute	A fee for orchestration and support
Cost of goods that scales with your usage	Yes	No
How visible the platform fee is	Hidden inside a blended bill	A naked line item next to your AWS bill

Where the old margin goes to die

A normal PaaS makes money on a markup. It buys compute wholesale from a hyperscaler, often at a committed-spend discount, runs your workload on shared infrastructure, and resells that capacity to you at a margin, usually somewhere in the 30 to 50 percent range. The compute is the product, and the spread between what they pay AWS and what they charge you is the business. The more you run, the more they make, because every CPU-hour you consume carries their markup baked in.

True BYOC breaks that model on purpose. Because the data plane sits in your cloud account, the compute and memory are billed directly to you by your own provider. The vendor never touches that money. They are not buying capacity and reselling it, so there is no spread to capture and no markup to grow. The thing a normal PaaS sells, infrastructure at a margin, is exactly the thing a BYOC vendor has given away. They have voluntarily stepped out of the middle of the compute transaction, which is the single biggest structural difference between the two business models and the reason you cannot just assume a BYOC vendor prices like a PaaS.

The revenue that replaces it

So what is left to sell? Orchestration, reconciliation, management and support. The vendor is no longer charging you for the compute; they are charging you for making the compute easy to run, keeping it in the state you asked for, and being on the hook when it drifts or breaks. That is a real product, but it is a fundamentally different one, and it forces a different pricing model. You see things like:

• per-seat pricing
• per-environment or per-cluster fees
• flat platform tiers
• usage metrics tied to deployments or managed resources rather than raw compute consumed

The pricing has to attach to the value the vendor actually delivers, because the value they used to deliver, cheap-ish blended compute, is no longer theirs to sell.

In some ways this is a cleaner business. There is no cost of goods that scales with your usage, so the vendor is not quietly bleeding margin every time your traffic spikes, and a runaway workload on your side does not blow up their gross margin. But it is a much harder business to price, and the difficulty is psychological as much as economic. In the old model, compute and markup were blended into one bill the vendor controlled, so you never saw the seam. In BYOC, you can see exactly what you pay the vendor and exactly what you pay AWS, side by side, as two separate line items. The platform fee is now nakedly visible next to the infrastructure bill, and the customer is constantly, quietly asking whether the orchestration is worth what it costs relative to the raw infrastructure sitting right next to it on the invoice. A PaaS never has to win that comparison because the customer never gets to make it. A BYOC vendor has to win it every billing cycle.

That visibility cuts both ways, and it is worth knowing as a buyer. It keeps a BYOC vendor honest, because they cannot hide a fat margin inside a compute bill, but it also means their pricing has to be legible enough to survive being stared at. When you evaluate one, the real question is not "is this cheaper than a PaaS." It is "is the orchestration layer worth a line item I can see, given the infrastructure bill I would be paying anyway." If a vendor cannot make that case clearly, the transparency that should have been their honesty becomes their problem.

If you want to feel the bones for yourself

Reading about BYOC only gets you so far. The two axes from earlier, abstraction and reconciliation, stay abstract until you have felt the permissions fight and the drift problem with your own hands. So if this is a model you want to actually understand rather than just evaluate, here is the path I would point you down, roughly in order.

1. Stand up a minimal control plane (or a Crossplane composition) and deploy a workload from it into a second cloud account using a cross-account role. This one exercise teaches more than any amount of reading, because it forces you to confront the two hard parts at once. You feel the permissions problem directly: the control plane is over here, the workload has to land over there, and the only thing connecting them is a role you have to scope correctly without handing over the keys to everything. And you feel the drift problem the moment something in that second account changes out from under you and your control plane has to notice and respond. That gap between "I asked for this state" and "reality has wandered off" is the whole game, and you cannot really internalise it from a diagram.

2. Write a CRD and a controller with controller-runtime. A custom resource definition plus a controller is the smallest honest version of "I own a spec and I reconcile it." You declare what a resource should look like, you write the loop that keeps checking whether reality matches, and you handle what happens when it does not. Doing this once demystifies the entire reconciliation half of the second axis, because you stop seeing reconciliation as a vendor's magic and start seeing it as a loop you yourself have written.

3. Study Crossplane as the canonical universal control plane. It is the clearest worked example of the portable-contract idea taken seriously: abstracting cloud resources behind compositions so the same claim can map to different providers. It is essentially the open-source embodiment of a lot of what the commercial BYOC vendors are doing behind their UIs, so reading how it is built tells you what is going on under the hood elsewhere.

4. Look at Cluster API (CAPI and its Azure flavour CAPZ) as the alternative approach, this time aimed at cluster lifecycle rather than general resources. Where Crossplane wants to be a universal control plane for everything, Cluster API is specifically about the birth, upgrade and death of Kubernetes clusters themselves. Learning the Crossplane-versus-CAPI tradeoff is worth doing deliberately, because it is the same product-shape question from the quadrant in miniature: how broad do you make the thing you reconcile, and what do you give up in depth when you go wide, or in breadth when you go deep.

5. Finish with the part nobody enjoys and everybody underestimates: Day-2 operations across a boundary you do not fully control. Upgrades, drift detection, observability, and incident response when you have limited access to the very environment the workload runs in. This is where BYOC stops being a clever architecture and becomes an actual operational discipline, because the data plane is in someone else's account and you cannot just SSH in and poke around when something is on fire. If the earlier exercises teach you how BYOC works, this one teaches you why it is hard to run, and that is the lesson that separates people who have read about BYOC from people who have actually lived with it.

Wrapping up

If you take one thing from all this, let it be that BYOC is a narrow word that has been stretched to cover a lot of things it does not really mean. The version worth the name is specific: your workloads and data run in your own cloud account, behind your own boundary, and the vendor never sees the bytes or stands between you and your infrastructure bill. Everything else, the products that see your data, terminate your requests, or resell you compute, can be perfectly good software. It is just answering a different question.

Once you hold that line, the rest of the picture falls into place:

• The control plane stays with the vendor and the data plane stays with you.
• The real players sit in one corner of the map, managed experience plus your-cloud execution, and the pretenders each miss on one axis or the other.
• The reasons to take this on come down to a benefit you can name in a single sentence, committed spend, a residency rule, a GPU reservation, and if you cannot name it, that is your answer.
• The thing that actually defines a given product is not its landing page but where it sits on two axes: how abstract its contract is, and who owns the source of truth it reconciles against.

The business shadow is the part I would not skip, because it explains the behaviour you will run into as a buyer. A BYOC vendor has walked away from the compute markup that funds a normal PaaS, which makes for a cleaner business but a harder one to price, and it puts their fee right next to your AWS bill where you can stare at it every month. That transparency is a feature if you are the customer. It just means the vendor has to be worth the line item, every cycle, in a way a PaaS never has to prove.

And if any of this made you want to understand it for real rather than from the outside, go build the small version. Stand up a control plane, push a workload into a second account through a cross-account role, write a controller that reconciles a spec, and then try to operate the whole thing across a boundary you do not fully own. That last part, the unglamorous Day-2 reality, is where BYOC stops being an architecture diagram and becomes a thing you actually understand.

Last thing, and I will say it plainly: this is my read of the space, assembled from my own work and from research across Northflank, Render and others while I was trying to get it straight in my own head. Treat it as one engineer's mental model, not gospel. If your experience points somewhere different, I would genuinely like to hear it.

Comments

[Marcus Kohlberg]

Nice writeup, but what about encore.dev?

[JOOJO DONTOH]

Thanks Marcus and I appreciate the time you have taken to read this.

Concerning the control and data planes I stated in the article I'm fairly confident that Encore sits with the true BYOC players. I can see that you have a dashboard, the parse-graph-and-provision pipeline amd tracing which sits with you and outside the user's account. I can also see that you provision into the user's Cloud provider (AWS and GCP) which supports the true byoc markers.
I can also see that the contract is quite portable, new SQLDatabase("orders") mapping to RDS or Cloud SQL from the same code is about as clean an example as I could ask for.

What I'd like to know is if you guys do continuous reconciliation. From the outside Encore looks like parse, provision, deploy on push, with the application code as the spec. What I can't tell is what happens between deploys, because if someone changes an instance size or a setting in the cloud console, does Encore detect that drift and pull it back to what the code declares, or is it provision-on-push and the next deploy is what re-asserts state? Also after something changes in the console what is your operation on which state to trust ?

[Marcus Kohlberg]

Yeah we can be clearer about how that works, it's documented here: encore.dev/docs/platform/infrastru...

Basically Encore supports two way updates i.e. before making any changes to a resource, Encore Cloud pulls the current resource properties from the cloud provider's API. If a difference in config is detected (e.g. a setting was changed directly in the cloud console), Encore updates its internal representation to match the current state. I.e. it assumes configuration changes made in the console take higher priority.

We're also working on adding a policy-in-code layer, to complement the declarative SDK provided today.