Skip to content

Knowledgebase

Preserving Active Storage uploads during deployment

development

Active Storage stores file metadata in the database and file contents in a configured storage service. A complete backup and migration must account for both.

What you need before you begin

Identify the production storage service, its credentials and any local disk path. List background analysis or preview tools required by the application.

01 Preserve Active Storage uploads during deployment

  1. Keep local uploaded-file storage outside disposable release directories, or use the configured durable external storage service.

  2. Provide the new release with the correct storage configuration and permissions. Keep storage credentials private and scoped to the required container or bucket.

  3. Deploy compatible Active Storage database migrations through the reviewed migration process. Do not assume a database export contains the uploaded file contents.

  4. Back up the database and file store with a recoverable relationship between them. Test restoration to a separate application environment.

  5. Verify upload, download, image variants and any preview processing the application actually uses. Confirm the relevant background jobs run.

02 Example: verify that a private attachment stays private

After restoring a harmless test attachment, test its download as the owning user, as a different signed-in account and in a private browser with no session. For a file meant to be confidential, only the authorized account should obtain it through the intended application route.

Active Storage's default controllers are publicly reachable; knowing a signed blob URL can grant access even when normal application pages require login. A private storage bucket alone does not apply your customer authorization rules. Use an authenticated, record-authorized delivery design for confidential attachments and review the default Active Storage routes so they cannot bypass that design. Re-test direct and variant URLs after changing routing, and ensure public images still work where public access is intentional.

Confirm the expected result

Upload a harmless test file, deploy a new release and confirm the file remains available. Check that private attachments are delivered through the application’s intended authorization design.

Troubleshoot unexpected results

A missing attachment after migration can mean metadata exists but the object was not transferred, or the new runtime uses another storage service. Check the object key and destination before deleting metadata.

A common question

Can I restore uploads by importing only the Rails database?

No. The database describes the attachments, while their contents live in the configured storage service. Restore both components using a coordinated recovery plan.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support