Automatic PR Comments

Squash automatically adds a comment on each Pull Request with one or more URLs where you can test your changes:


You can also customize the comments to allow listing multiple deployments and subdomains.


Unique Deployments per branch and Dockerfile/docker-compose file

Squash assigns a brand new virtual machine to each branch and Dockerfile/docker-compose file. For example, if your application has 2 different Dockerfiles then Squash will assign 2 separate URLs for each branch. Each URL runs on its own separate virtual machine.

Structure of a Squash deployment URL:

$ https://<branch-name>-<squash-unique-id>.squash.io



For the example above we have the following:

  • The original branch name in GitHub is cartv3_improvements. Squash automatically converts _ to - in URLs.
    • Squash also strips any special characters from the branch name that can’t be used within the URL schema.
  • i3xg7 is the Squash unique ID assigned to this deployment.
  • Squash always keeps the same URL between deployments of the same branch. If you make changes to the branch’s code, open/close/re-open Pull Requests, the URL will still remain the same.

Automatic Notifications of Code Changes

Once a deployment is up and running Squash automatically notifies when there are new code changes. You can restart the deployment anytime to get the latest version.


Configurable VM Sizes and Storage

For greater flexibility you can customize the VM sizes and storage of each deployment. This is available on several levels:

  • Account level: this will affect all repositories in your organization
  • Repository Level: this will overwrite the account level setting
  • Branch level: this will overwrite the repository setting

For more details, visit our list of available VM sizes and storage.

SSH Access

SSH access is available for debugging purposes for all deployments. The access is available from the Squash Admin interface a few minutes after starting a new deployment.


Once you connect to a deployment you can easily attach a shell to your docker containers. For example:

$ docker ps

$ docker exec -i -t a24a1a50752e /bin/bash

After the last command above you will get access to a shell within the Docker container.

Note that docker ps will only display results after the container is successfully built. This can take several minutes depending on the application.

Subdomains and multi-level subdomains

Squash supports a special syntax for dealing with any level of subdomains. This allows your application subdomains to still work with SSL/HTTPS without the need of separate SSL certificates.

Here is how it works: Squash translates any double dashes (--) within the hostname and converts them to subdomains when passing the request to the application’s backend. We also support multiple levels of subdomains.



When Squash receives this request it will translate it to the following URL when passing it to the backend - everything is transparent for the end user:



You can store files and data that needs to be shared across deployments. This is done through a special storage mount point that becomes available to all deployments within a repository.

You can upload up to 100GB of data in this folder (additional charges apply, check out our pricing page).

When the Assets Storage is enabled Squash will automatically add a new /assets/ mount point for all deployments within the repository.

This feature helps with the following use cases:

  • storing development database dumps that are made available to all deployments
  • product images
  • search index dumps/snapshots such as Solr or ElasticSearch snapshots
  • third-party application libraries/packages
  • any files that are important to share across deployments

The Assets Storage has read+write permissions by default and can be updated from the Squash interface or from any Squash deployment.

Docker Image Cache (Deployment Cache)

After the first deployment Squash automatically saves a cache of the Docker image generated by a Dockerfile or docker-compose file. This cache is then used to speed up new deployments.

Squash keeps a reference of every unique Dockerfile/docker-compose in the repository and re-uses its cache on deployments matching the same Dockerfile by name and md5sum. When a Dockerfile changes Squash automatically generates a new cache for that file.

Persistent Deployment Storage

You can enable the persistent storage on a per deployment basis. This is very helpful when you need to keep your application data intact between runs.

Basic HTTP Authentication

You can define Basic HTTP Authentication on an account level. These credentials will become available for all deployments on all repositories.

You may also define Basic Authentication within your Docker containers for greater flexibility.

Custom Expiration Time

By default Squash will automatically shut down your deployments after 6 hours to save you money. However, you can manually stop deployments any time. You may also define specific an expiration date and time for any deployments, keeping them live for longer or shorter periods of time.

Custom Domains and Custom SSL

Squash supports custom domains. You may associate one custom domain per Dockerfile or docker-compose file within your .squash.yml file. Once this is done all you need to do is to reach out to our support team and we will happily install a Free SSL certificate for your domain.

For more information on setting up your custom domain, go to the .squash.yml page.

Deployment Keys

By default Squash uses the SSH public keys of each user’s GitHub account associated with your Squash account. You may also upload custom deployment keys to allow access from different servers.

The Deployment Loading Page

When logged in:

If you are currently logged in to the Squash Admin interface then Squash will display a standard loading page with the full build log output and information regarding Docker Image Cache and Persistent Deployments.

When not logged in:

If you are not currently logged in to the Squash Admin interface then Squash will display a simple page with the last deployment time (if available) and current deployment time.

Build Logs are not displayed in this case to avoid exposing such details to untrusted users.