Spin Pro is now is available for Laravel!

Deploying your application with Spin

This guide is a continuation of the "Getting Started" section of the Spin documentation. In this section, we assumme created a project with Spin, and you want to use the spin deploy deployment strategy.

Prerequisites

Running your deployment

Once you have the prerequisites in place, you can run the spin deploy command to deploy your application to your server.

Deploy your application with Spin

spin deploy <environment>

By default the environment is production, but you can specify your own environment if you'd like. For example, if you have a staging environment, you can run spin deploy staging.

Using different .env files per environment

By default, everything runs off the .env file. This is great for local development, but it can be a challenge if you want to deploy to multiple environments from the same folder.

To solve this, you can create .env files for each environment you want to deploy to. For example, you can create .env.production and .env.staging files. When you run spin deploy production, the .env.production file will be used. When you run spin deploy staging, the .env.staging file will be used.

This approach is highly reliant on the framework you're using. For example, when you run spin deploy production, the APP_ENV variable will be set to production. Laravel is intelligent enough to know to use the .env.production file. If you're using a different framework, you might need to adjust your configuration to use this approach.

Be sure to add .env.* files to your .gitignore file so they are not committed to your repository.

What happens when you run spin deploy?

Running the spin deploy command automates the process of deploying your application to your server without the headache of worrying about CI/CD.

You can read more about the spin deploy command in the command reference. Long stort short, the spin deploy command does the following:

  1. Builds your application: The spin deploy command will package your application into a Docker image
  2. Creates a temporary Docker registry on your workstation: The Docker image is pushed to a temporary Docker registry on your workstation
  3. A SSH tunnel is created: A SSH tunnel is created to your server so it links to the temporary Docker registry
  4. The Docker image is pulled to your server: The Docker image is pulled from the temporary Docker registry to your server
  5. A Swarm Deployment is created: A Swarm deployment is created on your server with the new Docker image
  6. The temporary Docker registry is turned off: The temporary Docker registry is turned off on your workstation and the SSH tunnel is terminated

This process greatly reduces the knowledge and effort to complete a zero-downtime deployment.

This might not work best for all team sizes

While the spin deploy command is great for small teams or solo developers, it might not be the best solution for larger teams. If you have a larger team, you might want to consider setting up a CI/CD pipeline with Spin. This will allow you to have more control over your deployments and ensure that your team is following the same deployment process with improved credential management.

Always remember, Spin is a structure just as much as it is a tool. We ensure flexibility is always available to you so you can use Spin when you need it and Spin get's out of your way when you don't want to use it. To help larger teams, we created open-source workflows that can be used with GitHub actions to create zero-downtime deployments.

Learn more about setting up zero-downtime deployments with GitHub Actions