Managed Service Backups
Codesphere allows you to enable automated backups for your managed services to prevent data loss. This page covers the general backup concepts that apply to all managed services. Provider-specific configuration examples and limitations are documented on the respective provider pages.
Key Concepts
- Backup Store: The external storage location where your backups are saved. This can be an external S3-compatible service (like AWS S3) or a Codesphere S3 Managed Service.
- Retention Period: The number of days a backup is kept before it is automatically deleted by Codesphere (
deleteRetentionDays). - Interval: How often a new backup is created, measured in hours (
intervalH). Codesphere handles the scheduling automatically. - Recovery: Creating a new managed service in the exact state of a previous backup or point in time.
Checking Provider Capabilities
Not all managed services support backups or point-in-time recovery. To see if a provider supports it, you can check the /managed-services/providers API endpoint. The capabilities object will list two specific features:
backups: The provider supports taking automated backups and recovering a service to the exact state at the moment a specific backup was taken.pointInTimeRecovery: In addition to standard backups, the provider supports recovering a service to an arbitrary point in time (e.g., a specific minute) between two backups.
If pointInTimeRecovery is true, the backups capability will also be true.
You can also check the capabilities in the UI: the provider details page, which opens when you click Start setup on a provider card in the catalog, lists them as well.
Backups are currently supported for PostgreSQL, Babelfish, and DocumentDB, and can be saved to any S3-compatible backup store.
Enabling Backups
You can enable backups when creating a new managed service or by updating an existing one, either in the UI or via the API.
Via the UI
Services that support backups have a dedicated Backups tab in the service details sheet. The same settings are also available during service creation.
- Open the service details by clicking on a managed service in your team
- Navigate to the Backups tab
- Toggle Automatic Backups to enable backups
- Configure the following settings:
- Backup Frequency: How often backups are created (in hours)
- Retention Period: How many days backups are kept before automatic deletion
- Storage Destination: Your S3-compatible backup store endpoint, credentials, and path
- Click Save to apply your changes
Via the API
Provide the backups block in the request body with enabled: true, your intervalH, deleteRetentionDays, and your storage config and secrets. This works both when creating a new service (POST) and when updating an existing one (PATCH).
info
The values you provide for config and secrets (both in the backups block and the recoverFrom block below) can vary between providers. Codesphere validates them against the backups.configSchema and backups.secretsSchema defined by the provider. You can inspect these schemas in the response of the /managed-services/providers API endpoint, and find concrete examples in the provider documentation.
Viewing Backup History
Via the UI
The Restore section in the Backups tab displays a list of all completed backups with:
- Backup ID: Unique identifier for the backup
- Start Time: When the backup was initiated
- Finish Time: When the backup completed successfully
Via the API
List your managed services and check the backups.entries array of the service you are interested in:
curl "https://api.codesphere.com/managed-services?team=YOUR_TEAM_ID" \
-H "Authorization: Bearer YOUR_API_TOKEN"
{
"id": "8316ee2f-87f8-424e-b925-7382dc50d662",
"name": "my-postgres",
"backups": {
"enabled": true,
"intervalH": 12,
"deleteRetentionDays": 30,
"entries": [
{
"id": "0d95627e-2adf-4f04-9b3d-08d258f978c6",
"scheduledAt": "2026-07-12T19:38:49.410Z",
"initiatedAt": "2026-07-12T19:38:49.410Z",
"confirmedAt": "2026-07-12T19:38:49.410Z"
}
]
}
}
Each backup entry contains the backup id (which you can pass as the backup ID in recoverFrom when restoring), when it was scheduled and initiated, and confirmedAt — the time the backup was confirmed in the backup store.
Restoring from a Backup (Recovery)
Restoring a backup in Codesphere always creates a new managed service, rather than replacing the data in-place. The existing managed service remains untouched and completely independent.
To restore a backup, you create a new managed service and use the recoverFrom property to either specify a specific backup ID or — if the provider supports point-in-time recovery — a previous managed service ID with a recovery timestamp.
info
When recovering, the backups block is not strictly required.
It only controls if the recovered service is taking backups of itself.
For concrete recovery examples, see the provider documentation.
Triggering a Manual Backup
You can schedule an immediate on-demand backup for a service that has automatic backups enabled. Manual backups are created outside the regular schedule and do not affect your configured backup frequency.
Via the UI
In the Backups tab of your service details, click the Backup Now button. The button is disabled until automatic backups have been enabled and saved.
Via the API
Use the POST endpoint to schedule a backup:
curl -X POST "https://api.codesphere.com/managed-services/YOUR_SERVICE_ID/backups" \
-H "Authorization: Bearer YOUR_API_TOKEN"
info
As with enabling backups, the provider-specific config and secrets for your backup store must be provided in the request body. They are validated against the provider's backups.configSchema and backups.secretsSchema — check the provider documentation for concrete examples.
Disclaimers and Limitations
When using managed service backups, please keep the following in mind:
- User Responsibility for S3 Storage: Encryption and redundancy of backups are the responsibility of the user. You must ensure that the S3 storage you configure satisfies your organization's security and redundancy requirements.
- Bucket Capacity: It is your responsibility to make sure the backup store has enough free space. If the target bucket runs out of space or hits a quota, backups will fail.
- Backup Timing: There is no guarantee on the exact time that a scheduled backup will occur. The actual backup creation could be delayed by a couple of minutes depending on system load and network conditions.