LGPD on your PaaS: what changes when your deploy lives in Brazil

Brazil’s General Data Protection Law (LGPD, Lei 13.709/2018) took effect in 2020. Since then, most teams have treated it as a legal problem: privacy policy, cookie banner, hire a DPO, ship the checkbox.

It’s not. LGPD is, first and foremost, an architectural decision. Where your data runs, who operates the cluster, how you respond to a deletion request, in what jurisdiction your backup lives — all of this is the infrastructure layer. And that’s where most Brazilian teams are unprepared: they picked a global PaaS without reading the contract closely.

This post isn’t legal advice. It’s engineering. Let’s focus on what actually changes when the infra is Brazilian-by-design — and what doesn’t change, even when the app pretends it does.

Why LGPD became a DevOps problem

LGPD treats the operator with the same accountability as the controller. Translated for DevOps: the company that operates the infrastructure where your data lives is on the hook for LGPD compliance alongside you.

That means picking a PaaS is not only a stack decision — it’s a chain-of-accountability decision.

When your app sits on a US-based PaaS, three things happen by default:

1. Data crosses borders. Even if your user is in São Paulo, the request is usually routed to us-east-1 or eu-west-1.
2. The contract is governed by foreign law. If the provider is sued in the US, a US judge decides what happens to your data.
3. Support speaks another language. During real-world privacy incidents in 2023, response times suffered from timezone and language friction.

None of these show up in your framework checklist. They show up in Article 33 of LGPD (international transfer) and Article 18 (data subject rights).

International transfer: the blind spot

Article 33 allows international transfer of personal data, but only under specific cases — adequacy decision (ANPD has not published the official list yet), standard contractual clauses approved by ANPD, or explicit consent from the data subject.

In practice, most Brazilian teams using Vercel, Railway, Heroku, or Fly.io have none of those formalized. The default DPA from these providers covers GDPR, not LGPD. And asking for explicit consent on every international transfer per user is impractical.

The technical detail nobody mentions: even when a provider advertises a “São Paulo region,” the control plane (auth, billing, audit logs) typically still runs in the US. So part of your data — including sensitive metadata like access IPs, usage patterns, tenant structure — leaves the country.

Data subject rights (Art. 18): an engineering checklist

LGPD grants the data subject nine rights. Five of them have direct engineering impact:

1. Confirmation and access

The user asks: “what data do you have on me?”

You need an authenticated route that returns everything tied to that user. In practice:

SELECT * FROM users WHERE id = :user_id;
SELECT * FROM orders WHERE user_id = :user_id;
SELECT * FROM events WHERE user_id = :user_id;

The gotcha: most teams forget secondary sources — app logs, analytics events, backups. Those are personal data too.

2. Correction of incomplete or inaccurate data

A simple PATCH /users/me endpoint. The often-forgotten part: propagation. If the field is replicated to an external CRM, a CDP, or backups, every copy must be corrected. Replica auditing is part of the design.

3. Anonymization, blocking, or deletion

The user asks: “delete everything.”

The heavy one. Anonymization means breaking re-identifiability. UPDATE users SET email = 'deleted@x.com' WHERE id = :id isn’t enough — you need to think in terms of the dataset:

4. Data portability

The user asks: “export everything in a format I can import elsewhere.”

Structured JSON, explicit schema. CSV for tabular data. Important: the format must be interoperable — a proprietary SQL dump doesn’t count.

5. Deletion of data processed under consent

Different from #3: here the data subject revoked consent and wants only consent-based data deleted. Audit logs justified under a different legal basis (regulatory obligation, for example) can remain.

The engineering implication: legal basis per field. If you only record user consented, you lose the granularity.

Logs and PII: the most common leak

In a typical Brazilian PaaS audit, application logs are the most frequent PII leak source. A common scenario:

// WRONG — leaks CPF into logs
app.post('/checkout', (req, res) => {
  console.log('Checkout request:', req.body)
  // req.body.cpf now lives in Loki, S3, Datadog...
})

Logs flow to an observability service that typically:

• Runs in another region (international transfer)
• Has 30+ day retention (no TTL aligned with legal basis)
• Is accessible by the whole team (no RBAC)
• Has no automatic PII masking

Simple technical recommendation: sanitization middleware before the log driver. Explicit list of sensitive fields, explicitly masked.

const SENSITIVE = ['cpf', 'cnpj', 'rg', 'cnh', 'password', 'token', 'cardNumber']
function maskPII(obj) {
  const clone = { ...obj }
  SENSITIVE.forEach((k) => { if (clone[k]) clone[k] = '[REDACTED]' })
  return clone
}

How Upuai solves this by design

Upuai Cloud was born with Brazilian infrastructure — not as an available region, but as the only region. That changes the economics of the decision:

• Datacenters in Brazil (BH/MG), no international control plane. Your data, metadata, and logs never leave national territory.
• LGPD-ready DPA by default, no need to ask sales.
• Operator subject to ANPD, with Brazilian jurisdiction in case of incident.
• Portuguese support with SLA in Brazilian business hours.
• Native BRL, no IOF, no monthly FX swings.

The practical difference: you don’t add a compliance layer on top of the PaaS. It comes aligned out of the box.

# upuai.toml — deploy config
[build]
builder = "railpack"

[deploy]
startCommand = "node dist/server.js"
releaseCommand = "pnpm exec prisma migrate deploy"

And deploy is still git push. Compliance and ergonomics aren’t a tradeoff.

What’s next

LGPD is just the start. Upcoming posts will cover: encryption at rest, masked observability, retention aligned with legal basis, and how to model granular consent in a Brazilian app.

If your stack is on an international PaaS today and you want to see how it would look on 100% Brazilian infrastructure, check Upuai Cloud’s plans or read the upuai.toml docs — in 5 minutes you have an app deployed.