Persistent files and the ephemeral container

Your app runs in a container, and the container’s filesystem is ephemeral. Anything your app writes to disk is lost when the container restarts, when you deploy a new release, when you scale, and when AWS moves your app to another node.

Danger

Never keep data you care about on the container’s disk. That includes uploaded files, a SQLite database, generated reports and anything cached on disk that you can’t recreate.

What this means for a Django app

What	Do this instead
Database	Use a managed Postgres database. SQLite files are lost on every deploy.
User uploads (MEDIA_ROOT)	Store them in object storage such as Amazon S3, for example with django-storages.
Static files	collectstatic runs during the build, so they are baked into the image. Serve them with WhiteNoise or from object storage.
Sessions and cache	Use the database, or an external cache. Don’t rely on files or in-process memory, especially with more than one instance.
Scheduled and background work	Run it as a separate service. A process inside the web container stops whenever the container does.

More than one instance

If you scale to several instances, each has its own filesystem and its own memory. Anything that must be shared, such as sessions, caches and files, has to live outside the container.

Temporary files are fine

Use the disk freely for temporary work within a single request, for example resizing an image before sending it to S3. Just don’t expect it to be there later.