Why PlantLab Runs on European Infrastructure
Building on American cloud is the easy choice, which is exactly why almost everyone makes it. One account at Amazon, Google, or Microsoft and you get the whole stack in one place: compute, database, storage, DNS, email, all of it wired together, billed on one invoice, documented to death. It is a genuinely excellent product. It is also where PlantLab started.
It doesn't run there anymore. The diagnosis API, the database that holds your history, and the services around them now run on European infrastructure, and the live path a request travels – upload, inference, response, storage – never leaves the EU. That was not the easy choice. I want to explain why I think the easy choice and the right one were two different things here.
The all-in-one pitch is real, and it's the trap
The reason a hyperscaler is so easy to build on is that it has already solved the hard part for you: integration. You don't think about how your database talks to your storage, or whether your email provider and your DNS provider have ever heard of each other. One vendor owns all of it, so it all just fits. For a solo founder with limited hours, that convenience is worth a lot.
The catch is what you hand over in exchange. Your data, and the rules that govern it, now live inside one American company's estate, under one country's legal reach, no matter which “region” you tick in the console. An EU region of a US cloud is still a US cloud. The convenience and the loss of sovereignty are the same decision – you can't take one without the other.
For a lot of software that trade is fine. For a tool that gets handed photos from real, often licensed, grow rooms, I didn't think it was.
Europe is fractured, and that's the whole point
Here is the honest part nobody puts in the brochure: there is no European hyperscaler. There is no single EU console where you tick a box and get a sovereign, all-in-one stack. So you build it the hard way – you assemble it.
You host compute with one provider in one country. You find a separate DNS and content-delivery company in another. You put your database and transactional email with providers in a third. And before you trust any of them you do the unglamorous research: is this company actually European-owned and European-hosted, or is it a US firm with an EU postcode? Where does the data physically sit? Who can be compelled to hand it over, and under whose law? More vendors, more contracts, more reading, more things that can break.
That fragmentation is real, and it is the cost of sovereignty. The single invoice is convenient precisely because one entity controls everything. The moment you insist that no single entity should, you inherit the work of stitching independent pieces together yourself. I think that work is the point, not a bug to be engineered away.
What the assembling actually produced
Here is where things stand now. Three countries, several independent European providers, deliberately not one console:
| Layer | Where it runs now |
|---|---|
| Diagnosis API (the inference itself) | Germany |
| Database (your history, account, keys) | France |
| Transactional email | France |
| DNS and content delivery | Slovenia |
| Web analytics | EU-hosted, cookieless |
| Uptime monitoring | France |
The cutover was the careful kind. I ran the new European stack alongside the old one, sent real traffic through it, and verified end to end that a diagnosis written on the new infrastructure could be read back correctly, including the parts that are encrypted at rest. Only then did production point at it. The old environment is still sitting there, frozen, as a rollback target for a while longer, because turning the lights off the same day you cut over is how you turn a migration into an incident.
In an earlier post on data privacy I said this move was in progress and was careful not to overclaim it – the core diagnosis API still ran on a US cloud at the time. That caveat is gone now. The whole live path is European.
Why the hard road
I didn't do this for a marketing line, and I'm wary of anyone who treats “EU-hosted” as a badge. I did it because of what a plant photo actually is.
A photo of a flowering plant gives things away – that you grow, the kind of setup you run, and across enough images, the scale of it. For a licensed European operation that is commercially sensitive information sitting inside a regulatory frame. The question that operator asks before sending anything real is simple: where does my data live, and whose rules govern it? “On servers in Germany, under EU law, with no single foreign company holding the whole stack” is a different answer than “somewhere in a US cloud's European region.”
There is a regulatory tailwind too. Europe's high-risk AI obligations come into force in August 2026, and the broader direction on privacy keeps moving toward stronger consent and more transparency, not less. Building here now, while PlantLab is small and the change is cheap, beats retrofitting it under a deadline later. But the regulation is the tailwind, not the reason. None of this makes PlantLab a compliance product, and you should distrust any small tool that claims a certificate.
The reason is plainer than that. Data sovereignty, privacy, and digital rights belong to the person whose data it is – not to whichever cloud happens to be cheapest to build on. Most companies build on US infrastructure because it's easy and it works, and I understand why. I took the harder, more fragmented road because, for a tool handling this kind of data, the user is the one who matters most. The convenience was mine to give up. The data was never mine to be casual with.
What this changes for you
For most people using the API, the answer is: nothing you have to do, which is the point. The endpoints are the same, your API key is the same, the response format is the same. Inference still runs in milliseconds – the model didn't change, only the building it runs in. A migration you have to think about is a migration done badly.
What it changes is what's true underneath:
- Your diagnosis data is processed and stored in the EU. The live request path stays inside European infrastructure from upload to response, across providers that no single foreign entity controls.
- Sovereignty is distributed on purpose. No one company holds your data, your DNS, and your delivery layer at once. That's harder to run and harder to compromise wholesale.
- The privacy controls travel with it. Bounded, opt-in retention and encryption of the sensitive diagnosis fields ride on top of the move. Where your data lives and how it's held now point the same way.
If you opt in to contributing diagnoses on the free tier, those images are kept in EU storage as well. The default is still minimization: opt-in, bounded, then deleted.
Stated accurately, not stretched
“EU-based” is a phrase that gets stretched until it means a billing address. I'd rather it mean something concrete. Here it does: the request that carries your plant photo is served from Germany, your history is stored in the EU, traffic is measured by cookieless EU analytics, and uptime is watched by EU monitoring – each from an independent European provider. The live path your data travels, in real time, is European end to end. That's the claim, and it's a specific one.
PlantLab is free to try at plantlab.ai. Three diagnoses a day, results in milliseconds. The full API documentation, including data handling details, lives at plantlab.ai/docs.
FAQ
Where does PlantLab run now?
The diagnosis API is served from Germany, the database and transactional email are in France, and DNS and content delivery run from Slovenia. Analytics are cookieless and EU-hosted, and uptime monitoring runs from France – each from an independent European provider rather than a single all-in-one cloud. A diagnosis request stays inside the EU from upload to response.
Why not just use a US cloud's European region?
Because an EU region of a US company is still governed by that company and, ultimately, by US legal reach over it. Using independent European providers keeps the data physically in the EU and out of any single foreign entity's control. It's more work to run, which is the trade I chose to make.
Did the API change? Do I need to update anything?
No. The endpoints, your API key, and the response format are unchanged. Inference still runs in milliseconds. The move was designed to be invisible to integrators – nothing in your code needs to change.
Why does this matter for cannabis growers specifically?
A plant photo can reveal that you grow, the kind of operation you run, and at scale, how large it is. For a licensed European operation that's commercially sensitive and sits inside a regulatory frame. Data stored in the EU under EU law, across providers no single foreign company controls, is a stronger answer to “where does my grow data live” than data in a US cloud.
Does this make PlantLab GDPR or EU AI Act compliant?
EU-based infrastructure supports those goals but isn't a certificate, and no honest small tool should claim one. PlantLab pairs EU hosting with bounded opt-in retention, encryption of sensitive fields at rest, and cookieless analytics – controls that move in the same direction the regulation does.
Related reading: – A Plant Photo Says More Than You Think: Privacy by Design at PlantLab – What we keep, for how long, and why – How PlantLab Knows When It Might Be Wrong: The reliability_score Field – The trust signal on every diagnosis – What's Wrong With My Cannabis Plant? A Visual Diagnosis Guide – The grower-facing diagnostic hub