Destinations
Configure and test the seven storage destinations Devpilot can write backups to — local disk, Amazon S3, Azure Blob, SFTP, Google Cloud Storage, Google Drive, and Cloudinary.
A destination tells Devpilot where a plan's artifacts should live. One destination can back many plans, and a workspace can have as many destinations as it needs. This page documents each of the seven supported destination types, what you fill in for each, and how the connection test works.
Overview
Every destination has a friendly name, a type (one of the seven backends listed below), a set of non-sensitive settings like bucket or container, and a set of credentials that are stored encrypted at rest. You can mark one destination as the workspace default, in which case new plans pre-select it. Each destination also has a status (Active, Testing, Failed, or Disabled) and records the last time it was successfully tested.
You can create a destination from the Destinations area, or inline while you're creating a backup plan.
Supported destinations
Stores artifacts on the Devpilot server's local filesystem under a path you choose. Useful for demos, single-node deployments, or staging. Not recommended as the only destination for production data — local disks are not redundant.
You can optionally pick a base directory. Leave it blank and Devpilot uses its default backup folder. No credentials are required.
Stores artifacts in an Amazon S3 bucket (or any S3-compatible service).
You provide the bucket name, AWS region (for example us-east-1), and an optional key prefix like backups/prod/. For credentials, you paste in an AWS access key ID and secret access key with permission to write to that bucket.
S3 destinations also power user-facing downloads via presigned URLs — see Backup history.
Stores artifacts in an Azure Blob Storage container using Shared Key authentication.
You provide the storage account name, the container name, and an optional prefix inside the container. For credentials, you paste in the storage account's access key.
Stores artifacts on a remote server over SFTP. You can either point the destination at an existing Devpilot-managed server (which reuses its SSH credentials) or supply a host, port, and credentials directly.
You fill in the remote hostname or IP, the SSH port (typically 22), and the absolute remote directory to write into. For credentials, you either enter a username and password, or — preferred — a username with a private key and optional passphrase.
Stores artifacts in a Google Cloud Storage bucket.
You provide the bucket name and an optional object prefix. For credentials, you can paste a short-lived OAuth2 access token, or — recommended for long-lived access — upload a service-account JSON key.
Stores artifacts in a specific Google Drive folder.
You provide the Drive folder ID where backups should be uploaded. For credentials, you can paste a short-lived OAuth2 access token, or — recommended for long-lived access — supply a refresh token together with your OAuth client ID and secret.
Stores artifacts as raw assets in a Cloudinary account. Handy for image-heavy workspaces that already rely on Cloudinary.
You provide your Cloudinary cloud name and an optional prefix for the public ID. For credentials, you paste in the Cloudinary API key and secret.
Testing a destination
Devpilot gives you two checks:
- Test credentials — runs against the values you just typed, before you save. Use this from the create form to confirm an API key works without committing to a destination record.
- Test connection — runs against an already-saved destination. It either reports success with a short message, or surfaces the specific error that came back from the provider (for example "Access Denied" or "No such bucket").
Both tests attempt a lightweight round-trip — listing a bucket, opening an SFTP session, or issuing a signed OAuth request — so they catch credential, permission, and network issues without uploading a real backup.
While a test is in flight, the destination's status shows Testing. A success flips it back to Active and records the time of the test; a failure flips it to Failed and shows the error inline.
The default destination
Exactly one destination per workspace can be marked as the default. When you create a new plan and don't pick a destination explicitly, Devpilot uses the default. Marking a new default automatically clears the flag from the old one.
Use this when you have a catch-all bucket that most plans should write to, and make exceptions only for plans that need a different region, provider, or account.
Destination status
A destination is always in one of these states:
- Active — the destination passed its most recent test and is eligible to receive backups.
- Testing — a credentials or connection test is currently running.
- Failed — the last test failed. Plans pointing at a Failed destination will error on their next run until you fix the credentials and re-test.
- Disabled — the destination was manually disabled, for example while rotating keys. Plans skip it until it's re-enabled.
Limits and edge cases
- Rotating credentials on a destination takes effect immediately for future runs — re-test after editing to confirm.
- Deleting a destination that's still referenced by one or more plans will flip those plans to Disabled until you reassign them.
- For SFTP destinations backed by a Devpilot-managed server, updating the server's SSH credentials automatically propagates to the destination.
- Google Cloud and Google Drive tokens expire. If you supply only an access token and it expires, plan runs will start failing — provide a refresh token (Google Drive) or a service-account key file (GCS) for long-lived access.
Next steps
Backup plans
Create, schedule, pause, and run Devpilot backup plans for databases, files, and server images — with flexible intervals, cron, or real-time schedules and full retention controls.
Backup history
Browse every Devpilot backup run — filter by plan, status, or date; cancel in-progress jobs; download completed artifacts; and inspect file snapshots for file-type plans.