TeamJanuary 5, 20276 min read

Offboarding Developers Securely: Revoking Access to Shared Configs

When someone leaves the team: revoke their API token, rotate shared secrets, remove their machine, and verify everything with snapshot history.

The Offboarding Problem

When a developer leaves your organization, you need to revoke their access to everything: source code repositories, cloud consoles, CI/CD pipelines, and communication tools. Most companies have checklists for this. But developer environment secrets are almost always overlooked.

The departing developer's laptop contains production database credentials, AWS access keys, SSH keys to your servers, API tokens for third-party services, and environment files with secrets that may not exist anywhere else. If they used a dotfile manager or manual setup, there is no central system to revoke. You have to trust that they deleted everything.

With ConfigSync, offboarding is a structured process: revoke the token, rotate secrets, remove the machine, and verify with the audit trail.

Step 1: Revoke the API Token

Every machine in ConfigSync authenticates with an API token. Revoking that token immediately cuts off access to all synced configurations and secrets.

Revoke API token
# From the dashboard: Settings > API Tokens > Delete # Or via the API: $ curl -X DELETE https://configsync.dev/api/tokens/tok_departing_user \ -H "Authorization: Bearer cs_admin_token" { "success": true, "message": "Token revoked. 1 machine deauthorized." } # The departing user's next configsync command will fail: $ configsync pull Error: Authentication failed. Token has been revoked.
Token revocation is instant. The moment you delete the token, the departing developer cannot pull, push, or access any ConfigSync resources. There is no cache or grace period.

Step 2: Remove Their Machine

After revoking the token, remove their machine from your account. This cleans up the machine list and ensures their device no longer appears in your dashboard.

Remove machine from account
# List machines to find the departing user's device $ configsync machines list ID Name Last Sync Status ── ──── ───────── ────── m1 macbook-sean 2027-01-05T10:00Z Active m2 desktop-sean 2027-01-04T16:00Z Active m3 laptop-jordan 2027-01-03T09:00Z Revoked # Remove the revoked machine $ curl -X DELETE https://configsync.dev/api/machines/m3 \ -H "Authorization: Bearer cs_admin_token" { "success": true, "message": "Machine removed." }

Step 3: Rotate Shared Secrets

If the departing developer had access to shared team secrets, those secrets should be rotated. They were encrypted with the team's master password, and while the developer cannot access them through ConfigSync anymore, they may have copies on their local machine.

Rotate shared secrets
# Identify what the departing user had access to $ configsync history --machine laptop-jordan Last 5 snapshots for laptop-jordan: #47 Pulled: production env vars, AWS credentials #45 Pulled: staging database URL #42 Pulled: SSH keys, team git config ... # Rotate secrets they had access to $ configsync secret rotate DB_PASSWORD $ configsync secret rotate AWS_ACCESS_KEY_ID $ configsync secret rotate AWS_SECRET_ACCESS_KEY $ configsync secret rotate STRIPE_SECRET_KEY # Push rotated secrets to remaining team members $ configsync push -m "Rotated secrets - offboarding Jordan"

Step 4: Verify with Audit Trail

The snapshot history tells you exactly what the departing developer last accessed. This is critical for determining the scope of secret rotation needed.

ActionHow to VerifyWhat to Look For
Token revokedDashboard > TokensToken no longer listed
Machine removedconfigsync machines listDevice not in list
Last access timeconfigsync history --machineTimestamp of last pull
Secrets accessedconfigsync history --machineWhich tiers were pulled
Secrets rotatedconfigsync historyNew snapshot with rotations

The Offboarding Checklist

Here is the complete offboarding checklist for ConfigSync access:

Offboarding steps
# 1. Revoke their API token (instant access cutoff) DELETE /api/tokens/:token_id # 2. Remove their machine from the account DELETE /api/machines/:machine_id # 3. Review what they had access to configsync history --machine <their-machine> # 4. Rotate any production secrets they accessed configsync secret rotate <secret_name> # 5. Push rotated secrets to remaining machines configsync push -m "Secret rotation - offboarding" # 6. If they had access to the master password, rotate it configsync master-password rotate # (This re-encrypts all secrets with a new key)
If the departing developer knew the team master password, you should rotate it. This re-encrypts all secrets with a new key derived from the new password. Remaining team members will need the new password on their next pull.

Why Token-Based Auth Makes Offboarding Clean

The reason ConfigSync makes offboarding straightforward is that authentication is token-based. Each machine has its own token. Revoking one token does not affect any other machine. There is no shared credential to rotate (except the master password in extreme cases), no SSH key to remove from multiple servers, and no access list to update across services.

Compare this to the typical offboarding process for developer environments: ask the person to delete their local files, hope they do it, rotate every shared credential because you have no way to know what they copied, and update a dozen access lists across different services. ConfigSync reduces this to four API calls and a secret rotation.

Offboarding is one of those processes that organizations get wrong repeatedly because it is complex and infrequent. With ConfigSync, the process is simple, verifiable, and complete. Revoke the token, rotate the secrets, and move on.

Ready to try ConfigSync?

Sync your entire dev environment across machines in minutes. Free forever for up to 3 devices.

Get StartedRead the Docs