GitHub Repo
AutoGPT 0.8.0 adopts per-installation keys; deployments using defaults must migrate credentials
The release removes shared default keys and refuses to start with the old, publicly known encryption key. Existing credentials require re-encryption, while JWT verification compatibility changes and documentation gaps also affect upgrades.
AutoGPT released Platform 0.8.0 on September 19, switching self-hosted deployments to keys generated separately for each installation. The release removes default values for encryption, unsubscribe, and authentication service keys from configuration templates. The backend refuses to start with the old, publicly known encryption key. Deployments that already use their own keys do not need to rotate them for this change. [Release announcement](https://github.com/Significant-Gravitas/AutoGPT/releases/tag/autogpt-platform-beta-v0.8.0)
This directly affects the credentials agents store for external services. The official documentation uses Fernet to generate encryption keys, and its security depends on keeping those keys secret: anyone who obtains a key can read or forge the corresponding ciphertext. Shared, publicly known defaults therefore weaken protection for data at rest. This does not mean outsiders have gained access to the database, nor does it establish that a breach has occurred. [Self-hosting documentation](https://agpt.co/docs/platform/self-hosting/getting-started/), [Fernet documentation](https://cryptography.io/en/latest/fernet/)
Existing data also means that upgrading requires more than replacing environment variables. The announcement instructs operators to stop services and retain the old keys, generate new values, run a dry run with `rotate-encryption-key`, apply the re-encryption, and finally clear signing keys stored using the old authentication key. This procedure is intended to preserve connected integrations. Discarding the old encryption key outright removes the ability to decrypt existing ciphertext. [Migration steps](https://github.com/Significant-Gravitas/AutoGPT/releases/tag/autogpt-platform-beta-v0.8.0)
The authentication interface also has compatibility changes: the legacy HS256 JWT verification path has been removed, and `JWT_VERIFY_KEY` is no longer read. According to the official documentation, the backend retrieves login signing keys from the frontend’s JWKS endpoint. Connections between hosts over untrusted networks should use HTTPS. Replacing local secrets does not automatically secure key transmission. [Release announcement](https://github.com/Significant-Gravitas/AutoGPT/releases/tag/autogpt-platform-beta-v0.8.0), [Authentication architecture](https://agpt.co/docs/platform/self-hosting/getting-started/)
The encryption mechanism implies that database backups and keys must be managed as a matched pair. Restoring an old database while retaining the new key, or restoring only the old environment file while keeping the re-encrypted data, could leave the service unable to read credentials. Rollback rehearsals therefore need to cover both. Successfully starting the containers is not enough to establish that recovery is complete. This is an operational inference, not an automatic recovery feature promised by the announcement. [Keys and decryption requirements](https://cryptography.io/en/latest/fernet/)
At the time of review, the self-hosting guide still contained simplified instructions to generate new keys and replace the configuration values, without presenting the full re-encryption procedure in the announcement. Engineering teams should check their procedures against the release’s migration instructions and verify credential decryption, login, and workflow execution using a backup copy before scheduling the production upgrade. What can be confirmed is a change to the default configuration and upgrade behavior; the announcement itself provides no victim counts or evidence of a breach. [Self-hosting guide](https://agpt.co/docs/platform/self-hosting/getting-started/)