Speed up Kamal deploys in GitHub Actions

Have you got your application successfully deployed using but the deploy time still seems a bit too much? Depending on what changes you are trying to push to the server, ”a few minute“ deploys should be perfectly possible with GitHub Actions, even shorter ones:

around optimizing the Dockerfile itself and/or the building process but as they are not Kamal nor GitHub Actions–specific, we won’t cover them here. Besides, the default Ruby on Rails Dockerfile is already pretty optimized. So what other options do we have?

Cash everything you can

While I never recommend employing caching as the first step of optimizing things, Docker is an exception. The Docker image format is well suited for caching, the cached layers are immutable and their Docker to cache even the intermediate build layers, not only those exported to the final image. And we also give our build image some (arbitrary) name.

But in the context of GitHub Actions, this is not yet sufficient for caching to work. If you looked at the Actions ⟶ Caches tab in your GitHub repository, it would still be empty. How come?

By default, Kamal to build images which, in turn, uses the just for this so all that is needed is adding the action to the workflow file. We put it right after setting up Docker Buildx:

# .github/workflow/deploy.yml

jobs:

  deploy:

    steps:

      ...

      - name: Set up Docker Buildx

        uses: docker/setup-buildx-action@v3



      - name: Expose GitHub Runtime for cache

        uses: crazy-max/ghaction-github-runtime@v3

If you run the build action again, you should start seeing "buildkit" entries in the Actions tab ⟶ Caches in your GitHub repository:

of various package managers. For ruby, caching the bundled gems is are based on the x64 architecture so if your target server is ARM-based, your options are currently quite limited. You can:

• switch to one of the and are not free even for public repositories,




• in GitHub Actions, namely macos-14, macos-15, and macos-latest that run on the Apple silicon (M1) chip. Unfortunately, this setup . Since the GitHub Action runner itself is virtualized and Docker needs that too, there is effectively nested virtualization), there won’t be a feasible way to deploy to ARM-based servers natively using MacOS runners. In other words, until then, standard GitHub Action runners are best suited for deploying to x64 architecture servers only.

  
  
  

  
  
  
  Don’t build multi-platform images unless you really need them
  

  
  
  

  Unless you have multiple target servers that are mixed in their architectures, do not build multi-platform images. Building images for multiple architectures is inherently slow and there isn’t much you can do about it.

  
  
  

  So, be sure you have a single arch specified in the builder section of Kamal config. For reasons mentioned above, preferably amd64:
  
  

  
  
  
  
  

  CODE Kopieren

  # config/deploy.yml
  
  builder:
  
    arch: amd64
  
  

  
  
  
  
  
  
  
  

  
  
  
  Parallelize building native gems (misc tweak)
  

  
  
  

  We have also tested whether Bundler is able to determine the number of processors in a GitHub Action run so that it can parallelize gem downloads and builds (see its an by GitHub just a few days ago: a place to monitor the performance statistics of your GitHub Actions. To view them, go to Insights ⟶ Actions Performance Metrics in your repository and you will see something like the following:

  
  
  

  🦋.

  Vollständiger Original-Bericht

  Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

  ↗ Original-Artikel auf dev.to lesen