📘 This article is about static assets served by your app such as CSS or JavaScript files. If you’re looking for strategies for storing files uploaded by or generated for your customers, see How do I accept file uploads when using Aptible? instead.Broadly speaking, there are two ways to serve static assets from an Aptible web app:
❗️ This approach is typically only appropriate for development and staging apps. See Serving static assets from a third-party object store or CDN to understand why and review a production-ready approach. Note that using a third-party object store is often simpler to maintain as well.Using this method, you’ll serve assets from the same web container that is serving application requests on Aptible. Many web frameworks (such as Django or Rails) have asset serving mechanisms that you can use to build assets, and will automatically serve assets for you after you’ve done so. Typically, you’ll have to run an asset pre-compilation step ahead of time for this to work. Ideally, you want do so in your
Dockerfile
to ensure the assets are built once and are available in your web containers.
Unfortunately, in many frameworks, building assets requires access to at least a subset of your app’s configuration (e.g., for Rails, at the very least, you’ll need RAILS_ENV
to be set, perhaps more depending on your app), but building Docker images is normally done without configuration.
Here are a few solutions you can use to work around this problem:
.aptible.env
Dockerfile
:
📘 Review Accessing Configuration variables during the Docker build for more information about .aptible.env
and important caveats.
ENTRYPOINT
in your image to do the same thing.
An upside of this approach is that all your configuration variables will be available when the container starts, so this approach is largely guaranteed to work as long as there is no bug in your app.
However, an important downside of this approach is that it will slow down the startup of your containers: instead of building assets once and for all when building your image, your app will rebuild them every time it starts. This includes restarts triggered by Container Recovery should your app crash.
Overall, this approach is only suitable if your asset build is fairly quick and/or you can tolerate a slower startup.
DJANGO_SETTINGS_MODULE=myapp.static_settings
prior to running collectstatic
For a Rails app, you’d do that by creating a minimal RAILS_ENV
dedicated to building assets and settings e.g. RAILS_ENV=assets
prior to running assets:precompile
.
If you can take the time to refactor your App slightly, this approach is by far the best one if you are going to serve assets from your container.
📘 Considering the low pricing of object stores and the relatively small size of most application assets, you might not need to bother with cleaning up older assets: keeping them around may cost you only a few cents per month.
before_release
commands on Aptible.
.aptible.yml
file: