How it Works – Quick Intro
Squash works by creating unique testing URLs for each branch of code. This is by default integrated with Pull Requests (or Merge Requests in GitLab) in your favorite hosted version control system: GitHub, Bitbucket or GitLab. When you create a new Pull Request Squash will automatically post a comment like this:
The Squash comment above can be customized to support multiple applications, subdomains and to also include specific URL paths and query strings.
You can also manually generate deployment URLs from the Squash Web Interface:
The application build process
Squash was designed from the ground up to support complex web applications and microservices. Any web applications that can run in a Linux machine will run on Squash.
How a Squash URL works
When you click on the URL for the first time Squash will immediately start deploying it. In this case you will see a loading page like this (more info on the visibility of the loading page and logs):
Then once your application starts responding with a successful HTTP response Squash will automatically route all requests to your app and you will start seeing it from that same URL, like this:
Deployment URL life cycle
Your application will continue to work off this same URL according to its auto shutdown policy, you have lot’s of flexibility to control for how long you want these environments to live. Squash takes care of eliminating server waste, making sure your environments are available only when you need them.
What happens when a deployment URL expires
After the deployment’s expire time is reached, that environment will automatically be decommissioned. But don’t worry, next time you click on the same deployment URL, if the deployment is no longer available, Squash will automatically start it again.
Sometimes you may also enable persistent storage to keep all your data intact between runs.
Want to know more? checkout our list of features.