Signing up gets you a running instance. What matters is the loop you run inside it: protect data as it lands, declare what's personal, delete on request, and walk away with proof instead of a promise. Here's each step in plain language.
Skip this if you signed up hosted — Chameleon provisions your instance and emails you a console URL and password directly, nothing to run. Self-serve puts you a few terminal commands away from a running instance in your own GCP project.
Planning to customize the Terraform for your own product? Fork it first — it's your own repo from there, nothing you push to it ever reaches Chameleon's. Otherwise clone it directly:
git clone https://github.com/BrechtVanBuggenhout/chameleon-installer.git cd chameleon-installer
By default your instance pulls Chameleon's pre-built images — simplest, and what most customers want. If you'd rather not depend on Chameleon's container registry staying up indefinitely, all three services' source is public. This builds and pushes them to your own project:
./scripts/build-own-images.sh <your-gcp-project-id> [region]
Prints three image URIs when it's done — you'll need them in the next step.
Download the file from your status page or the email Chameleon sent you, and put it at the root of the clone as terraform.tfvars. If you built your own images in step 2, swap in those three image URIs — the file arrives with Chameleon's pre-built ones by default.
One command creates the Terraform state bucket, enables the required GCP APIs, and applies everything:
./scripts/bootstrap.sh <instance_name> <environment> <gcp_project_id> [region]
Takes 10-15 minutes. On success it prints your console URL and a generated password.
Open the console, ingest a test record, trigger a deletion, and confirm a certificate renders. That's the actual proof the install worked — see INSTALL.md for the exact commands for this and everything above.
Onboarding — self-serve or hosted — gets you to a working console. From there, every customer runs the same underlying loop regardless of which path they signed up through.
PII fields route through the Key Vault at write time and get encrypted with a per-user key before they ever touch the warehouse. What lands in your tables is ciphertext, not plaintext — so a warehouse breach or an over-permissioned analyst role never exposes raw personal data.
In your console, you mark which warehouse tables and columns hold PII. This builds a live registry — the answer to "where does personal data live" that most teams currently keep in a spreadsheet, if they keep it anywhere at all.
When a deletion request comes in — a DSAR, an account closure, a retention policy firing — you destroy that user's key instead of hunting down and deleting their rows. Every copy of their data across every table and backup that used that key becomes unreadable at once.
Chameleon issues a signed, timestamped certificate: which key was destroyed, when, and which systems held the encrypted data. That's what you show an auditor, a regulator, or a requester who wants evidence, not just your word that it happened.
Before Chameleon, "delete this user's data" usually means someone on the data team writing a one-off script: find every table that might reference the user, run DELETE statements, hope the backups age out before anyone asks, and produce no record of any of it if they do ask.
After onboarding, that entire process is a single action in your console. The registry from step 2 tells Chameleon what's in scope, the key destruction in step 3 makes it unreadable everywhere at once, and the certificate from step 4 is generated automatically — nothing to write, nothing to remember to run.
Do I need to change my data pipeline to use Chameleon?
Yes, minimally: the fields you want protected need to route through the Key Vault at write time so they land in the warehouse encrypted rather than as plaintext. For most teams this is a small change to an existing ingestion job, not a pipeline rewrite.
How do I tell Chameleon which fields are PII?
Through the declare flow in your own console — no ticket to Chameleon, no waiting. You pick the warehouse tables and columns that hold personal data, and Chameleon starts tracking them in the PII registry immediately.
What actually happens when I run a deletion request?
Chameleon destroys that user's encryption key rather than searching for and deleting rows. Every copy of their data that was ever encrypted with that key — including copies sitting in backups — becomes unreadable in the same operation, and connected downstream systems get a cleanup instruction too.
What do I get back as proof?
A signed, timestamped certificate recording the destroyed key's fingerprint, the destruction time, and which systems the encrypted data touched. That's the artifact you hand a regulator, auditor, or a DSAR requester who asks for evidence, not just an assertion that deletion happened.
The mechanism behind step 3 and step 4: how destroying one key makes every copy of a user's data unreadable, instantly.
Self-serve or hosted — what each path requires from you and what the first week looks like.
Ready to run this loop yourself? The signup form takes a couple minutes.