Continuous Delivery

Let's be honest - you didn't become a developer to wrestle with CI/CD pipelines. You want to be building amazing products, not debugging why your GitHub Action is suddenly taking 45 minutes to complete.

Instead of fiddling with deployment workflow, let sherpa.sh do all the heavy lifting for you. Just connect a Github repo and we'll handle the rest.

Zero-Config Deployments

Link your GitHub repository, and you're done. No YAML files to configure, no build matrices to optimize, no runners to maintain. We automatically:

• Detect your framework and dependencies

• Configure optimal build settings (which you can customize as needed)

• Set up production-grade deployment pipelines

• Handle all the CI/CD infrastructure

Anatomy of a Build

Every deployment follows a carefully orchestrated sequence of steps. Here's what happens behind the scenes:

1. Creating Cache Storage

We maintain a globally distributed, high-performance caching layer. This layer is used by frameworks for ISR, PPR, and other caching functionality. This step allocates a slice of the caching layer for your application.

2. Version Control Checkout

Shallow fetches your latest code from GitHub.

3. Environment Configuration

Securely fetches your environment variables from our secrets vault and injects them into the build context.

4. Dependency Installation

Installs your project dependencies based on your provided build configuration.

5. Project Build

Builds your application, optimizes assets, and prepares the production bundles.

6. CDN Asset Upload

Distributes your static assets across our global CDN network.

7. Route Function Building

Compiles, optimizes, then containerizes your application's server-side components and API routes.

8. Infrastructure Deployment

Provisions and configures the necessary cloud resources to run your application. We handle all the infrastructure heavy lifting, setting appropriate scaling rules and networking setup based on your selected plan.

9. DNS Update

Once your application is live and static assets uploaded, its safe to update DNS records to point to the new deployment. If you are using a custom domain this is when it gets routed to your application - otherwise we use the default speficied in the app configuration. We also provision SSL certificates using LetsEncrypt for your domain in this step. Doing this step ensures zero-downtime and a smooth cutover for every user.

Deployment Triggers

Your code gets deployed automatically when:

• You push to your production branch

• A new pull request is opened

• New commits land on a PR branch

Each trigger spawns a deployment pipeline that handles everything from dependency installation to final deployment. No manual intervention required.

Preview Environments

Surprises are for birthdays, not software. Every pull request gets its own complete preview environment. This means:

• Stakeholders can review changes on a real URL

• QA can test features in isolation

• You can catch issues before they hit production

• Each preview is an exact replica of what the branch would look like in production (yes, this means the build and deployment include your application environment variables)

When a new pull request is opened it triggers a deployment of that branch. It will be available at the subdomain in your app configuration with the branch name appended. For example if your subdomain is set to myapp.sherpa.softwareand your branch name is dev-feat-1 your feature branch will be available at myapp-dev-feat-1.sherpa.software.

Any new commits to a branch with an open pull request will also trigger a new deployment.

Github Integration

When a new build is triggered - or a build completes - sherpa.sh will leave comments on the pull request with links to the most up to date information.

Deployments will also trigger build checks and github deployment objects to be created. Both will be updated based on the success/failure of the build.

Instant Rollbacks

Made a mistake? No problem. Every deployment is immutable and cached globally. Rolling back is as simple as clicking a button in the "Deployments" tab.

To rollback (or promote a newer deployment):

1. Navigate to the Deployment table.

2. Search for the deployment you wish to rollback.

3. Click the Ellipse at the end of the table row

4. Click promote/rollback

Environment Variables: Previous deployments may not have the most up to date environment variables. Because some frameworks will embed the variables into the build output they cannot be updated new ones. If you need to rollback to a previous commit with new environment variables, we suggest pushing your current changes to a new branch, rolling back Head on the existing branch, then redeploying.

Rollback Limitations: In some cases you will not be able to rollback to your previous deployment. You should be aware of these scenarios:

1. You can only rollback to applications in the configured region for your application. For example, if your app settings currently target us-east, but your previous deployments are in us-west. You will not be able to rollback to them until you change your app settings back to us-wesGetting Started

1. Connect your GitHub repository (one click)

2. Add your environment variables

3. Push to your production branch

That's it. Seriously, we're not kidding. Here is the quickstart docs.

Now, go build something awesome instead of babysitting your CI/CD pipeline!