A Plant Photo Says More Than You Think: Privacy by Design at PlantLab
The Short Version
When you send a plant photo to a diagnosis API, you are not just sending a picture of a leaf. You are sending a signal about what you grow, roughly where, and sometimes at what scale. PlantLab treats that as sensitive data. Diagnosis history is kept only if you opt in, only for a bounded window, and the sensitive parts are encrypted at rest. Analytics are cookieless, the supporting infrastructure is moving toward EU providers, and your API key is shown once and never emailed back to you in full. None of this is glamorous. All of it is the difference between an API you can hand real grow-room data and one you can't.
A leaf photo is more revealing than it looks
A single diagnosis request looks harmless: an image, a response, done in milliseconds. But the picture itself gives things away. A flowering cannabis plant in frame implies cultivation. A steady stream of them implies an operation. Add metadata, timing, and volume and you can start to estimate scale. For a hobby grower that's a privacy preference. For a licensed facility it's commercially sensitive – and in much of the world, cannabis cultivation sits inside a regulatory frame where careless data handling is a liability, not just bad manners.
The honest way to think about this is to assume the data matters before anyone proves it does. The cost of treating a plant photo as sensitive is small. The cost of treating it as disposable and being wrong is not.
That assumption is the whole design principle: keep what is genuinely useful, keep it for a bounded period, and make raw database access far less useful to anyone who shouldn't have it.
What we keep, and for how long
PlantLab can show you your past diagnoses through the diagnosis history endpoint. That feature is useful – it lets you track a plant over time and gives integrators a stable record to reference. But I treat history as a choice you make, not a default I impose on you.
- Retention is opt-in. Storing your diagnosis history, and using images for model improvement, happens against a clear consent disclosure, not silently.
- Retention is bounded by tier. History is kept for a defined window – 90 days on Pro, 365 days on Business – and then cleaned up automatically on a nightly schedule. The window is a published number, not an open-ended “until we feel like deleting it.”
- Deletion is the default end state. When the window passes, the record goes. There is no quiet long tail of old data accumulating because nobody wrote the cleanup job.
The principle here is data minimization by calendar. The most private record is the one that no longer exists, and the cheapest way to guarantee that is to delete on a schedule rather than on request.
Encryption at rest, stated accurately
Sensitive diagnosis fields are encrypted at rest. If someone were to obtain a raw copy of the database, the sensitive columns would not be readable as plain text.
I want to be precise about what that claim is and isn't, because “encrypted” is a word I've watched get stretched until it means nothing. PlantLab encrypts the sensitive diagnosis fields – not a hand-wavy “the whole database is encrypted, trust us.” The design uses standard, portable PostgreSQL encryption rather than a proprietary scheme, so it can be audited, reasoned about, and moved between environments without leaning on one vendor's black box. The point is narrow and real: it raises the cost of a database compromise from “read everything” to “read very little.” One layer, described as one layer.
Your API key is yours, shown once
A practical piece of the same posture: PlantLab no longer emails raw API keys. When you create a key, you see it once in the interface, with an acknowledgement step and a rotate button. The follow-up email contains only a safe prefix so you can identify which key it refers to – never the full secret.
This matters because email is a long-lived, widely-synced, frequently-breached store. A secret that lands in an inbox lives in that inbox, on every device synced to it, in every backup of it, indefinitely. Showing a key once in the UI and never transmitting it in full keeps the most sensitive credential out of the least private channel. Sensitive account actions are also recorded in a structured way, so there is an audit trail for the things that should have one.
Cookieless analytics and a move toward EU infrastructure
Two more changes are visible if you look closely at how the site behaves.
The analytics are cookieless. I replaced Google Analytics with a privacy-native setup that sets no advertising cookie, which is why you won't see a cookie wall on the site. It counts aggregate traffic, not individual visitors followed around the web.
The infrastructure is also moving toward EU providers. Over the last few months I shifted content delivery and DNS off a US-centric stack onto an EU-based CDN, and moved transactional email to a provider in France. Analytics are EU-hosted too. This is a migration in progress, not a finished state – the core diagnosis API still runs on major cloud infrastructure today – and it would be dishonest to claim the whole stack has relocated. The honest version: I'm deliberately moving supporting services toward EU-friendly providers, and that work is still going.
That direction is not an accident of taste. Data-protection expectations are tightening, not loosening. The EU's high-risk AI obligations come into force in August 2026, and broader privacy regulation keeps moving toward stronger consent, retention discipline, and transparency about automated decisions. Building the quiet controls now – bounded retention, encryption, cookieless measurement, EU-leaning infrastructure – is cheaper than retrofitting them under a deadline. None of this makes PlantLab a compliance product, and you should be suspicious of any small tool that claims a regulatory certification. It makes PlantLab an API that is moving in the same direction the rules are.
Why bother, when nobody asks
Privacy work is invisible by design. No grower opens an app and thinks, “I appreciate that the diagnosis history is deleted on a 90-day schedule and the sensitive columns are encrypted.” The feature you notice is the diagnosis. The privacy work only becomes visible the day something goes wrong, and by then it's too late to add it.
The reason to do it anyway is that an automation API gets handed real data from real grow rooms. The more useful PlantLab becomes – feeding dashboards, triggering Home Assistant automations, logging plant state over a full grow cycle – the more that data accumulates and the more it matters how it's held. The boring controls are what make the useful version safe enough to actually use.
That's the trade. Privacy work is quiet, it doesn't demo well, and it's the part of building a plant health API that has to be right before any of the interesting parts are worth trusting.
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
Does PlantLab store my plant photos?
Storing diagnosis history and using images for model improvement is opt-in, disclosed through a consent step rather than enabled silently. If you opt in, history is kept for a bounded window per tier (90 days on Pro, 365 days on Business) and then deleted automatically. The default posture is minimization – keep what's useful, for a defined period, then remove it.
What does “encrypted at rest” actually mean here?
The sensitive diagnosis fields are stored encrypted in the database using standard, portable PostgreSQL encryption. If someone obtained a raw copy of the database, those fields would not be readable as plain text. It's a specific control on specific fields, not a blanket “the whole system is encrypted” claim.
Is my API key safe?
Your key is shown once in the interface when you create it, with a rotate option. PlantLab does not email raw keys – the email contains only a safe prefix so you can identify the key. The full secret stays out of your inbox.
Is PlantLab EU-based?
PlantLab is deliberately moving supporting services – CDN, DNS, email, analytics – toward EU providers, and analytics are cookieless and EU-hosted. This is a migration in progress; the core diagnosis API still runs on major cloud infrastructure. I'd rather describe it accurately than overclaim a finished relocation.
Why does plant diagnosis data need privacy at all?
Because a cannabis plant photo gives things away – that you're growing, the kind of setup you run, and across many photos, the scale of it. For a licensed operation that's commercially sensitive and often regulated. Treating it as sensitive by default costs little; treating it as disposable and being wrong costs a lot.
Related reading: – How PlantLab Knows When It Might Be Wrong: The reliability_score Field – The trust signal on every diagnosis – How PlantLab's AI Diagnoses 31 Cannabis Plant Problems in 18 Milliseconds – The pipeline behind the API – What's Wrong With My Cannabis Plant? A Visual Diagnosis Guide – The grower-facing diagnostic hub