In the first week of October 2026, two hosting platforms shipped changes that point the same way. On 7 October Heroku announced Team Authorizations: "team-owned API tokens and OAuth credentials for CI/CD pipelines and API integrations, replacing individual user tokens in automated workflows". The same day, DigitalOcean let every user choose their own session length, "from 1 hour to 30 days", and added organisation-wide limits on Droplets, Volumes, Databases and Load Balancers.
Neither announcement sets an end date for anything. Heroku's post does not say personal tokens are going away; it says team-owned credentials replace them in automated workflows. That narrower point is the useful one, because it names a failure most small teams have built into their deploy pipeline without noticing.
The deploy key that belongs to one person
Look at the secret your CI uses to deploy. In many teams it is a personal API token, created by whoever set the pipeline up, pasted into the CI's secret store and never thought about again. It works perfectly until one of these happens:
- That person leaves. Their account is closed, as it should be, and every deploy starts failing with an authentication error, usually on the day you need to ship a fix.
- That person rotates their token for a good reason, such as a laptop being lost, and silently breaks production deploys they had forgotten they were holding up.
- The token is too powerful. A personal token usually carries everything its owner can do. A CI job that only needs to push one app holds the keys to every app, database and billing setting that person can touch.
- Nobody can tell who did what. When a deploy is made with Alice's token, the audit trail says Alice deployed, whether Alice was involved or not.
None of these is exotic. They are the ordinary consequences of tying a machine's credential to a human's account.
What good looks like
The fix is not a particular product. It is a handful of habits that work on any platform:
- Give automation its own identity. Where your platform offers team-owned or machine credentials, use them for CI. Where it does not, create a dedicated account for deployments, owned by the team rather than a person, and generate the CI token from that.
- Scope it to the job. Prefer a credential that can do one thing, such as deploying one app or reading one repository, over one that can do everything.
- Prefer per-repository deploy keys for pulling code. A read-only SSH deploy key added to a single repository lets a server fetch that code and nothing else. If it leaks, you revoke one key on one repository.
- Write down where every credential lives. For each pipeline: which secret it uses, whose account it belongs to, and who can rotate it. Ten minutes now saves an outage later.
- Rotate on a schedule, not in a panic. A credential you rotate every quarter is one you know how to rotate. A credential nobody has touched in three years is one nobody dares touch.
- Make offboarding include credentials. When someone leaves, the checklist should ask "which pipelines used their tokens?" before their account is closed, not after deploys break.
How this maps onto DeployBase today
We would rather describe what our platform actually does than promise features. Today:
- The DeployBase API token belongs to a user account. Each account has one token. Regenerating it replaces the old one, and you can revoke it from your account settings. There are no team-owned tokens yet, so the advice above applies directly: if CI deploys through our API, generate that token from a dedicated deployment account rather than a person's.
- Git deployment uses a per-app deploy key. In an app's Deployment via Git tab, DeployBase generates an SSH key for that app; you add the public key to your repository as a read-only deploy key. It can pull that one repository and nothing else, and it does not depend on anyone's personal GitHub account. Git deployment is available from the Pro plan.
- Auto-deploy uses a per-app webhook secret, also shown in the Git tab, so a push to your repository triggers a deploy without a personal token anywhere in the loop.
The combination that holds up best is the read-only deploy key for code plus the webhook for triggering, with any API token kept on an account the team owns.
A five-minute audit
- Open your CI's secret store and list every token in it.
- For each one, write down which account created it.
- If any belongs to a single person, move it to a team-owned or dedicated account this week.
- Check that no deploy secret can do more than deploy.
The platforms are moving towards team-owned credentials for a reason. You do not need to wait for yours to do it for you.
Sources, read 8 October 2026: Heroku, "October 2026 Update: Heroku Innovations and Features", 7 October 2026 (heroku.com/blog); DigitalOcean, "Resource limits and session duration", 7 October 2026 (digitalocean.com/blog).