# Automating your deployments

# Why automate your deployment?

In practice, it's not ideal to deploy your projects from your local development environment. That's because the Ymir CLI will package all the files in your WordPress project including uncommited files. This isn't something that you might want especially when deploying to production.

In this scenario, you might want to look at automating your deployment. Ymir makes it easy for you to deploy your project using your favourite continuous integration platform.

# Creating an API token

All that you need is an API token. To create one, go to the account management page (opens new window) and scroll down to the Manage API Tokens section.

create api token

The Ymir CLI will look for the YMIR_API_TOKEN environment variable. So, once the API token created, you'll need to add it as an environment variable in your continuous integration workflow.

# Continuous integration platforms

Thew following section explains how to set up a basic automated deployment workflow with different continuous integration platforms.

# GitHub actions

First, you're going to need to create a secret to store your API token. Secrets are encrypted environment variables that allow you to store sensitive information safely. You can read more about them and how to create them here (opens new window)

You can name your secret whatever you want. That said, for this example, the secret name will be YMIR_API_TOKEN like the environment variable. You can see it in the same workflow below.

name: Deploy to production

      - main

    name: Deploy to production
    runs-on: ubuntu-latest
      - uses: actions/checkout@v2
      - name: Setup PHP
        uses: shivammathur/setup-php@2.9.0
          php-version: '7.4'
      - name: Install Ymir CLI
        run: composer global require ymirapp/cli
      - name: Deploy
        run: ymir deploy production
          YMIR_API_TOKEN: ${{ secrets.YMIR_API_TOKEN }}

This sample workflow will deploy your project to production whenever a commit gets pushed to the main branch. You'll want to use master branch if you have an older GitHub repository.