🚀
sherpa.sh docs
HomeInfrastructureAboutPricingDocsSign Up
  • Getting Started
    • What is sherpa.sh?
    • Getting Started
    • App Configuration
    • Custom Domains
    • Regions
  • TRAINING
    • Video Courses
      • Lesson 1: Deploying your first application
  • Applications
    • Supported Frameworks
      • Sveltekit
      • Next.js
      • React
      • Payload CMS
      • Docker
      • Custom Setups
    • Supported AI Website Builders
    • Continuous Delivery
    • CDN & Caching
  • Promotions & Rollbacks
  • Debugging
  • Securing your Application
  • Databases
    • Managed Databases
      • Postgres
      • MySQL
      • MongoDB
  • Architecture
    • Architecture Overview
      • Next.js Architecture
    • Compliance
  • Integration Help
    • Clerk
  • Zero Downtime Migration
  • CHANGELOG
    • v0.4.0 - 22/5/25
    • v0.3.2 - 4/5/25
    • v0.3.1 - 22/4/25
    • v0.3.0 - 9/04/25
    • v0.2.0 - 27/03/25
    • v0.1.0 - 21/03/25
Powered by GitBook
On this page
  • How Sherpa Deployments Work
  • The Developer Experience
  • Future Features

Promotions & Rollbacks

Nothing stings quite like a broken production deployment. We've all been there – that late-night debugging and productino patching after a buggy release hits your users. Sherpa's deployment system was born to make those painful experiences a distant memory.

Our deployment system gives you:

  • Zero-downtime updates - Your application stays available during deployments

  • Instant rollbacks - Made a mistake? One click and you're back to safety

  • Progressive traffic shifting - Test new versions with a portion of users before full commitment

  • Confidence in your deployments - Know exactly what's happening at each step

We built this system because we were tired of deployment anxiety. The feeling of pushing code and holding your breath isn't sustainable. Your deployments should be boring (in a good way).

How Sherpa Deployments Work

The Basics: Green-Green Deployments

Sherpa uses a "green-green" deployment strategy. Unlike blue-green deployments where you maintain two environments, we dynamically create new instances while keeping existing ones running.

Here's the flow:

  1. You push new code to your repository

  2. Sherpa creates a new containers in our k8s clusters with your changes

  3. Both your current and new code run simultaneously (both green!)

  4. Traffic gradually shifts to the new version after health checks pass

  5. Once fully shifted, old instances are gracefully terminated

This approach means you always have a healthy system running, with controlled traffic management between versions.

Health Verification

Sherpa won't route traffic to unhealthy instances. We rigorously check:

  • Readiness probes: Verify if your application is ready to receive traffic

  • Liveness probes: Continuously monitor if your application is healthy

  • Startup probes: Check if your application has started successfully

Currently, all probes are directed to "/" of your application. A future release will allow you to customize this variable.

Only when all health checks pass does Sherpa consider your deployment ready for traffic.

The Developer Experience

Promoting a Deployment

Promoting a deployment with Sherpa is straightforward, just merge your branch into production on Github. Sherpa.sh will automatically pick up the change and create a new deployment to promote.

Rollbacks: Your Safety Net

Sometimes things go wrong - and that's okay. Sherpa's rollback is immediate:

  1. Navigate to your project's deployment history

  2. Click "Rollback" on any previous successful deployment

  3. Traffic instantly returns to the previous version

Your users won't even notice there was an issue. That's the point.

Domain settings control ingress separate from your deployements. Be careful changing url settings post-deployment if you plan to do rollbacks to deployments from long ago.

So, If you changed your domain settings (updated the url) of your application, you may experience issues rolling back to a deployment before you chaned the url settings.

For example: Nextjs projects has a asset prefix setting that tells nextjs what url to find your static assets. If you're previous deployment has assets at myproject.example.com and you changed your url to hello.example.com. If you rollback to the deployment with myproject.example.com, the myproject url will still be in your deployments code and that url will no longer resolve. Because it's now set to hello.example.com.

Future Features

In the future we plan to support multiple promotion strategies beyond "green green" including:

  • Green Green: Switch all traffic immediately when pod is ready

  • Canary: Gradually shift traffic based on a timeline (10% → 50% → 100%)

  • Scheduled: Set a specific time for promotion

  • Split: Send a % of traffic to the new deployment until ready to promote all traffic.

  • Other: Have a unique request? Contact us below.

PreviousCDN & CachingNextDebugging

Last updated 2 months ago

If you would like to see this implemented sooner than later, please .

contact us