SLW / devportal Production apps Signing in…
Guides & Rules · Roles & access
Roles & access

Who does what — teammates and App Operators.

Almost everyone is a teammate: you build and ship without asking anyone for access. An App Operator is a granted role for the few who also stand apps up — repo, database, hosting, portal — without being an account admin anywhere. This page is the rulebook: what the role grants, who holds it, the rules of the road, and exactly how a migration works.

1

The two roles

Everyone on the team · automatic

🧑‍💻 Teammate

You already have this — it comes with your @slw.vc sign-in.

  • Use the apps — one login for every production app.
  • Build safely — Claude Desktop connects you to a dev copy of any app; production data never reaches you.
  • Ship — normal changes merge on green CI, no sign-off needed.
  • Protected paths — database schema and deploy config route to Shawn for review automatically.
A granted role · ask Shawn

🛠️ App Operator

Everything a teammate does, plus provisioning — standing up the things apps run on.

  • +Create app repos, Supabase databases, Vercel / Cloudflare hosting.
  • +Migrate whole apps into the stack — the five-stage flow below.
  • +Still never billing, org admin, or the gated approvals — the same protected paths apply to operators too.
💡Rule of thumb: changing an app is teammate work, creating an app is operator work. If you hit something your access can't do, it's usually an operator (or owner) step — ask, don't work around it.
2

What an App Operator can do

Least privilege on every platform: enough to build and run apps, never enough to touch billing or delete an organization. Day to day it splits into two tiers:

Operate — the everyday

Build, deploy, iterate

Code, hosting, env vars, CI, portal listing. Unrestricted on green CI — this is most of the work.

Provision — the guarded step

Databases & data

Creating a database and copying data runs through the migration script (backup → restore → verify), so the one destructive step can’t be fumbled.

PlatformCan doCan’t do
GitHubrivent-devCreate app repos, push, merge PRs, set CI & secrets on their own appsChange settings on shared repos, delete the org, billing
SupabaseSLW DatabasesCreate & manage project databases, run migrationsDelete the org, billing, manage members
Vercelslw1010Deploy apps, manage project env varsBilling, delete the team
Cloudflarerivent.devDeploy Pages, edit rivent.dev DNSAccount admin, other zones
Replitsource appsOpen, edit & export ReplsTeam billing & members
🛡️
Guardrails still apply on top. The sensitive paths — database schema and production / deploy config — stay gated by review (CODEOWNERS + rulesets), so even a repo-admin operator can’t bypass sign-off on those. Whoever creates a repo is its admin; the shared repos stay Write-only.
3

Who holds each role right now

Live from the same roster the portal uses. Everyone else with an @slw.vc sign-in is a teammate.

PersonRoleStatus
Loading the roster…

Add or remove an operator

One command on the server grants the role — it handles GitHub + Vercel automatically and prints the three manual invites (Cloudflare, Supabase, Replit). Remove someone by taking them out of the same five places.

$ add-app-operator <github-username> <email>
4

The rules of the road

Seven rules cover every scenario. They keep operators fast on the safe things and careful on the few that matter.

1

You own what you build

You’re admin on any repo you create. Org rules still gate the database and production paths — those changes need review, no matter who you are.

2

Small & verified goes straight to main

If it’s small and tests pass, ship it. Features, migrations, and anything risky go through a pull request with green CI.

3

Never hand-copy a database

Data moves only through the migration script. It backs up first, restores, and verifies row counts — so the one irreversible step can’t go wrong quietly.

4

Each app gets its own database

A production DB plus a -dev twin, following the house pattern. Spinning them up is your call — just be intentional: each active database ≈ $10/mo (~$20 for the pair).

5

Dev never holds real production data

Practice data only in dev and experiment databases. Real SLW data or secrets go into a dev environment only with Shawn’s OK.

6

One repo per app, in rivent-dev

Named for the app; its database matches the name. Keeps the portal, Codespaces, and databases lined up one-to-one.

7

People are added & removed in one place

Use add-app-operator to grant the role. Reverse it by removing them from the same five platforms — membership is the access.

5

Migrating an app off Replit

Five stages, same every time. The one that decides the path is Stage 1 — whether the app has a real database.

STAGE 1

Diagnose

Run the report prompt in the Replit Agent. It reports the stack, the secrets it needs, and — the deciding question — whether it has a Postgres database.

STAGE 2

Code out

A new repo in rivent-dev, code pushed, Replit-specific bits stripped out.

STAGE 3

Database

If it has one, the script creates its Supabase project (prod + dev), copies the data across, and verifies it. Skipped entirely for apps with no database.

STAGE 4

Hosting & kit

Deploy to Vercel or Cloudflare, load the secrets, add a devcontainer + CI, and list it on the portal.

STAGE 5

Cut over

Smoke-test the live app, then turn the Replit app off. Nothing is deleted until the new one is proven.

Where it ends up living — the same shape as every other SLW app:

Source
GitHub
rivent-dev / <app>
Database
Supabase
its own project (+ dev)
Hosting
Vercel / CF
under rivent.dev
Dev in
Codespace
via devcontainer
Old Replit
Retired
off after cutover
6

Questions & scenarios

The situations that actually come up — click any to expand.

Am I an operator?
Check the roster in section 3 — if you’re not on it, you’re a teammate, which covers everything except creating repos, databases and hosting. Need the role? Ask Shawn; it’s one command to grant.
I want to migrate one of my Replit apps.
Start with the diagnose step — run the report prompt in that app’s Replit Agent so we know the stack and whether it has a database. Then it’s the five stages above. If several apps are moving, pilot one first to prove the flow, then batch the rest.
My app needs a database — what happens to the data?
It gets its own Supabase project (a production database and a -dev twin). The migration script copies your data across with a backup taken first and a row-count check after, so nothing is lost. Budget ≈ $10/mo per active database (~$20 for the pair), billed to the org.
How do I make someone an App Operator?
Run add-app-operator <github-username> <email> on the server. It adds them to GitHub + Vercel automatically and prints the three manual invites (Cloudflare, Supabase, Replit). They accept the GitHub and Vercel emails, and they’re in.
How do I remove someone?
Take them out of the same five platforms they were added to — GitHub team, Vercel, Cloudflare, Supabase, Replit. Membership is the access, so removing it revokes everything. Apps and databases they built stay put; they’re owned by the org, not the person.
I need to do something an operator can’t.
That’s an owner action by design — billing, deleting an organization, org-wide settings, or a change to a gated production/database path. Ask Shawn. The role deliberately stops short of these so a mistake or a compromised account can’t reach them.
Who pays for the databases and hosting?
The org (SLW). Supabase is on the Pro plan; each additional active database ≈ $10/mo. Vercel and Cloudflare usage is org-billed too. Operators can create these resources — the spend guardrail is Rule 4: be intentional.
What happens to the old Replit app?
It keeps running untouched until the migrated app is smoke-tested and confirmed live. Only then do you turn Replit off. Nothing is deleted mid-migration — there’s always a working version.
Can an operator change a production app or its database?
Not directly. Day-to-day app changes ship on green CI, but production/deploy config and database schema are gated by review — even for repo admins. That’s the line between “operate” and “owner-approved.”
Where will my app live after moving?
Code in GitHub (rivent-dev), its own Supabase database, hosted on Vercel or Cloudflare under rivent.dev, and developed in a Codespace — identical to every other SLW app, so anyone on the team can pick it up.