All tools
Tools / GitHub Actions builder

GitHub Actions Workflow Builder

Pick your language, triggers and deploy target, and get a ready-to-commit CI/CD workflow. It uses current action versions, least-privilege permissions and keyless AWS login (OIDC).

Start from a template

Workflow

When should it run?

Tags matching v*, e.g. v1.2.0 Adds workflow_dispatch

Separate several branches or paths with commas. Need help with cron? Try the cron builder.

Language and build

Several versions or systems create a test matrix: one job for each combination.

Extras

Docker image

Deploy

.github/workflows/ci.yml


        

      

    


    

    

      
How to use the workflow

      
    
        
  1. Create the folder .github/workflows/ in the root of your repository.
    2. 
        
  2. Save the generated YAML there, for example as .github/workflows/ci.yml, then commit and push.
    3. 
        
  3. Add any secrets or variables listed under the YAML in Settings → Secrets and variables → Actions.
    4. 
        
  4. Open the Actions tab of your repository to watch the run. With Manual run button ticked you can also start it from there.
    5. 
      

      
What the parts of a workflow mean

      

        
onThe events that start the workflow: pushes, pull requests, a schedule (cron, always in UTC), a manual button (workflow_dispatch) and many more. Branch and path filters narrow them down.

        
permissionsWhat the automatic GITHUB_TOKEN may do. The builder sets contents: read for the whole workflow and only grants extra rights (pushing packages, deploying Pages, requesting an AWS login token) to the job that needs them. This limits the damage a compromised dependency could do.

        
concurrencyGroups runs by branch so a new push cancels the run that is still testing the previous commit. When the workflow deploys, only pull request runs are cancelled, so a deploy is never cut off halfway.

        
jobs and needsJobs run in parallel on fresh virtual machines unless needs makes one wait for another. Here, the Docker and deploy jobs only start after the build job passes.

        
strategy.matrixRuns the same job once for every combination of values, for example three Node.js versions on Linux and Windows makes six jobs. fail-fast: false lets the other combinations finish when one fails, so you see every failure.

        
uses and runA step either runs a reusable action (uses: actions/checkout@v7) or a shell command (run: npm test). The @v7 part pins the major version, so you get fixes but no breaking changes.

        
environmentDeploy jobs run in a named environment (production or github-pages). In the repository settings you can require a manual approval or limit which branches may deploy to it.

      

      
Deploying to AWS without access keys

      
The S3 and ECR options log in to AWS with OpenID Connect (OIDC) instead of long-lived access keys. GitHub gives each run a short-lived token, and AWS trades it for temporary credentials for one IAM role. Nothing secret is stored except the role's ARN. To set it up once:

      
    
        
  1. In IAM, add an identity provider of type OpenID Connect with the URL https://token.actions.githubusercontent.com and the audience sts.amazonaws.com.
    2. 
        
  2. Create a role that trusts that provider. Limit the trust policy to your repository and branch with the condition token.actions.githubusercontent.com:sub = repo:OWNER/REPO:ref:refs/heads/main (or repo:OWNER/REPO:environment:production).
    3. 
        
  3. Give the role only what the deploy needs: s3:ListBucket, s3:PutObject and s3:DeleteObject on the bucket, and cloudfront:CreateInvalidation on the distribution.
    4. 
        
  4. Save the role ARN as the secret AWS_ROLE_ARN and the distribution ID as the variable CLOUDFRONT_DISTRIBUTION_ID.
    5. 
      

      
Tips