Deploy with least privilege
The schema’s in files. The tool deploys it. So you hand the deploy job to a service account, point it at production, and walk away — and the account you handed it has db_owner, because that’s what got the demo working six months ago.
Hey folks. I’m Forge Barrett, master of the Content Forge here at SchemaSmith.
Courses 1 through 5 got your schema forged and version-controlled. This track is about operating it — deploying into production where the question isn’t “is the schema right?” but “who’s running this, what can they touch, and what stops a deploy from doing damage nobody asked for?”
Two layers hold the line
Section titled “Two layers hold the line”A safe deploy isn’t one careful operator remembering not to do the wrong thing. It’s two independent guardrails, and either one alone catches the mistake:
- The profile — what SchemaSmith will do on this run. A full quench reconciles structure: it adds, alters, and can drop. But a deploy can be told to do far less — run only your migration scripts, touch no table structure at all. That’s a setting, declared in the package, not a habit.
- The account — what the deployer can do, no matter what it’s told. An account with no rights to drop a table can’t drop one, whether the profile asks it to or whether a typo does. The boundary is enforced by what the credential physically can’t reach.
Lean on only the first and a misconfigured run can still overreach. Lean on only the second and you’re fighting the engine on every legitimate change. Set both, and a deploy does exactly what you meant — provably.
”Just give it create-table rights”
Section titled “”Just give it create-table rights””Here’s where operators get burned. You ask your DBA for “rights to create a table” — your migration needs to stand up a rollback backup before it touches anything. Reasonable. What you get back, more often than not, is ALTER on the whole schema. And ALTER on a schema is a drop in disguise: it lets the account delete and rewrite every table in it.
You asked for a hammer and got handed the keys to the whole smithy. The fix isn’t to trust harder — it’s to ask for a grant you can prove is narrow. This track shows you how: give the deploy account its own schema to work in, and CREATE TABLE there needs no power at all over the tables you’re protecting.
The track opens with a datafix
Section titled “The track opens with a datafix”The first recipe is the one every team hits: production data is wrong and you need to fix it — carefully, reversibly, and without a god-mode account.
Module 1 · Datafix & limited-privilege deployment ships a data-only correction across a fleet of tenant databases, deploying as a scoped account that can read, write, and back up — but can’t drop or alter your tables. One tenant first as a canary, then the rest. You’ll prove the boundary holds by trying to break it.
More operations recipes are coming from the forge — pre-flight checks, CI gates, patch packaging. Start here, because least privilege is the habit the rest build on.
New to SchemaSmith? Get the CLI on your PATH first — Course 1, Module 1 walks the install in a couple of minutes. Come back when schemaquench --version answers.
Check yourself: Why isn't 'a careful operator' enough to keep a deploy from doing structural damage?
Because one careful person is a single point of failure — a typo, a wrong settings file, or a misread profile slips past attention. Two independent guardrails don’t: the deployment profile limits what SchemaSmith will attempt on a run, and the deploy account limits what the credential can do at all. Either one alone stops an overreaching deploy, so the boundary doesn’t depend on anyone remembering it.
Anybody can make the metal hot. An operator decides exactly how much heat reaches the work, and builds the forge so it can’t scorch what it’s not meant to touch. That’s the whole craft of deploying — least power that still does the job, proven, not promised.
Running deploys under an account you’ve never actually audited? Email me at forgebarrett@schemasmith.com — tell me what it’s granted and I’ll tell you where it’s wider than you think.
Next up: Course 6 · Module 1 — Datafix & limited-privilege deployment, where we fix a fleet of mispriced orders as an account that couldn’t drop a table if it tried.
Until then, may your grants stay narrow, your guardrails stay doubled, and nothing you deploy ever reach further than you meant.
— Forge