Deployment files

This page answers:

• Which files are uploaded to Shuttle when I deploy?
• How do I change which files are uploaded?
• How to serve static frontend assets on Shuttle?
• What happens to files after I deploy?
• What happens to files that I write to disk?

​

Files uploaded in deployment

When you run cargo shuttle deploy, all source files in your cargo workspace that are not ignored by .gitignore or .ignore rules are packed into a tar-gzip archive and uploaded to Shuttle, where they are then extracted, built, and hosted.

​

Ignore files

Ignoring files can be done by adding rules to .gitignore or .ignore files, depending on if you want to exclude them from version control or not.

​

Include ignored files

If you have ignored files that you want to include in the deployment upload, declare those files in the assets list in the Shuttle.toml file in the root of your workspace:

# Declare ignored files that should be included in deployment:
assets = [
  "file.txt", # include file.txt
  "frontend/dist/*", # include all files and subdirs in frontend/dist/
  "static/*", # include all files and subdirs in static/
]

​

Debug deployment files

You can double check which files are included in your deployment by turning on detailed logging:

cargo shuttle --debug deploy

​

Serving static files

Serving a web project often means that there are static HTML, CSS, or JavaScript files to serve.

To serve them on Shuttle, make sure they are included in the deployment (if they are gitignored), and then set up your project’s web framework to serve them from their directory.

An example on how to do this with Axum can be found here.

​

Deploying other useful artifacts

If your project needs some binary, library, or other useful resource (in file form) to build and run correctly in deployment, you can simply place it in your workspace, gitignore it if you want, and include it in your deployment.

​

What happens to my files?

Your files are unpacked, built and executed in a Docker container. Your app is executed inside the project directory, in the same way that cargo would.

When you deploy again, the project directory is cleared, and the new deployment’s files are placed there. This means that files saved to this directory are deleted at the time of a new deployment.

Files saved in other parts of the filesystem, such as /tmp, will be cleared when the container restarts, which is done when you run cargo shuttle project restart.

To persist data across deploys and container restarts, use a database or shuttle-persist.