Mounts

Types

Volume · Bind · File

Effect

Container recreated, no build

Backup

Volumes only (manual/scheduled, S3)

When do you need a mount?

A container's filesystem disappears on every deploy — the old container is removed, a new one is created from the image. Anything the application writes to disk needs to live in a mount if it should survive.

Three kinds of mount

Adding a mount

1. Open the Mount tab → Add mount

   Pick a Kind, set the Container path (unique per application), then Volume name / Host path / File content depending on the kind.

   Kind	Container path	Source	Notes
   Volume	/app/uploads	uploads	Volume aoox_app_shop_uploads
   Volume	/data	data	SQLite / cache
   Bind	/srv/media	/mnt/storage/media	Host path, owner/admin
   File	/etc/nginx/conf.d/app.conf	(content in the textarea)	Read-only

2. The container is recreated automatically

   Every add/edit/delete of a mount triggers a container recreate from the current image — no build. The application restarts briefly; env and domain are re-applied too.

3. Verify

   The Deploy tab's container log shows the application restarting. To confirm the path is mounted, run a manual job ls -la /app/uploads with target In the container.

Mounts for managed databases

The database page also has a Mount tab with the same three kinds — usually for engine config files or an extra volume:

• Any mount change reprovisions the database container (a brief restart; data stays in its volume).
• The same role rule applies: bind mounts are owner/admin only.
• Volume backup is only for application mounts; a database's own data volume is already covered by database backup.

File mounts

File contents are written directly in the Mount tab (a textarea), then Save & apply — handy for config that changes often without a repo commit.

server {
  listen 80;
  location / { proxy_pass http://127.0.0.1:3000; }
}

• Under the hood, all of an application's files are written to one dedicated volume (aoox_app_<app>_files) and then bind-mounted per path as read-only.
• An application that needs to write to that file must use a volume instead of a file mount.

Deleting a mount

Behavior & limitations

• PR previews get no mounts — don't share a production volume with an arbitrary branch.
• During blue/green, the two temporary containers share the same volume. Applications that lock files (SQLite without WAL) are better off with a host port so plain replace is used instead.
• A job with target Separate container inherits all of the application's mounts — good for migrations or data cleanup.
• Bind mounts are restricted to owner/admin since they're equivalent to host filesystem access.

Volume backup

The Volume backup section on the Mount tab: manual backups, a cron schedule, retention, and an S3 destination per application. Restore = stop the container → empty the volume → extract → start. Details in Backup & restore.

Next steps