Rolling Back a Broken SolidJS Deployment in Under 30 Seconds

You push a commit, the build passes, the deploy completes, and users immediately report a blank screen. You open the browser console and see "Uncaught TypeError: Cannot read property 'map' of undefined." The new code broke. You need the old version live again, right now, while you debug the issue locally.

Rolling back a deployment means redeploying a previous version without rebuilding from source. The static assets are already compiled and stored; you just tell the CDN to serve the old version instead of the new one. On most platforms this takes two clicks. Here's how it works for a SolidJS + Vite app.

How deployment history works

Every time you deploy, the platform stores:

• The compiled static assets (dist/)
• The commit SHA and branch name
• The environment variables at deploy time
• Build logs and deployment metadata

These are kept for a retention period (10 days on Free, 30 days on Pro, 90 days on Premium). Within that window, you can roll back to any previous deployment instantly.

Rolling back via the dashboard

1. 1Open the project in the dashboard.
2. 2Click the Deployments tab.
3. 3You see a list of recent deployments, newest first.
4. 4Click the three-dot menu on the last working deployment.
5. 5Click Rollback.
6. 6The platform redeploys that version — no rebuild, just a cache swap.

The rollback completes in under 30 seconds. Users see the old version, the bug is gone, and you have time to fix the issue.

Rolling back via the API

For automated rollbacks (e.g. triggered by a monitoring alert), call the API:

# List recent deployments
curl https://api.pandastack.io/v1/projects/<project-id>/deployments \
  -H "Authorization: Bearer $PANDASTACK_TOKEN"

Response:

{
  "success": true,
  "data": {
    "deployments": [
      {
        "deploymentId": "dep_123",
        "status": "COMPLETED",
        "commitSha": "abc123",
        "createdAt": "2026-08-05T10:15:00Z"
      },
      {
        "deploymentId": "dep_122",
        "status": "COMPLETED",
        "commitSha": "def456",
        "createdAt": "2026-08-05T09:00:00Z"
      }
    ]
  }
}

The first deployment (dep_123) is the current (broken) one. The second (dep_122) is the last working version. Roll back to it:

curl -X POST https://api.pandastack.io/v1/projects/<project-id>/deployments/dep_122/rollback \
  -H "Authorization: Bearer $PANDASTACK_TOKEN"

Response:

{
  "success": true,
  "data": {
    "deploymentId": "dep_124",
    "status": "DEPLOYING"
  }
}

A new deployment (dep_124) is created, pointing at the same compiled assets as dep_122. The CDN cache is purged, and within seconds, users see the old version.

Rolling back via the CLI

panda login
panda projects info <project-id>

This shows recent deployments. Copy the ID of the last working one, then:

panda projects rollback <project-id> --deployment-id dep_122

The CLI triggers the rollback and streams the status. When it shows "Deployment completed," the rollback is live.

What rollback does NOT do

• Does not revert the Git commit. Your main branch still has the broken code. You need to fix it and push a new commit.
• Does not change environment variables. If the broken deploy introduced a new env var (e.g. PUBLIC_API_URL), the rollback uses the old deployment's env vars, not the current ones. If you've changed secrets since then, the rollback might fail due to missing credentials.
• Does not rebuild the code. If the old deployment was deleted (past the retention period), rollback fails. You'd need to redeploy from the Git commit instead.

Debugging why the deploy broke

After rolling back, figure out what went wrong. Common causes for SolidJS + Vite apps:

1. Undefined props in a component

// Broken: assumes `items` is always defined
function List(props) {
  return (
    <ul>
      <For each={props.items}>
        {(item) => <li>{item.name}</li>}
      </For>
    </ul>
  );
}

If props.items is undefined (e.g. an API call failed), SolidJS crashes at runtime. Fix:

function List(props) {
  return (
    <ul>
      <For each={props.items || []}>
        {(item) => <li>{item.name}</li>}
      </For>
    </ul>
  );
}

2. Environment variable changed at build time

Vite embeds import.meta.env.PUBLIC_API_URL into the bundle as a literal string. If you changed the env var in the dashboard but didn't redeploy, the old value is still in the compiled code.

Fix: trigger a new deploy (which rebuilds with the new env var) or set the env var before the deploy, not after.

3. Dependency version mismatch

You upgraded solid-js locally, tested it, forgot to commit the updated package-lock.json. The local build works, the CI build (which installs from package.json without the lockfile) picks a different version, and the app breaks.

Fix: always commit package-lock.json, yarn.lock, or pnpm-lock.yaml.

Preventing broken deploys with preview environments

Instead of deploying to production on every push, deploy to a preview environment first (per pull request or per branch). Test the preview URL, and only merge to main when you're confident it works.

See the earlier post on preview environments for Next.js — the same workflow applies to SolidJS.

Automating rollback on errors

If you have monitoring (Sentry, LogRocket, custom error tracking), you can trigger a rollback automatically when the error rate spikes. Example GitHub Actions workflow:

name: Auto-rollback on errors

on:
  schedule:
    - cron: '*/5 * * * *' # Every 5 minutes

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Check error rate
        id: check
        run: |
          # Fetch error count from Sentry API
          ERROR_COUNT=$(curl -s https://sentry.io/api/0/projects/.../stats/ \
            -H "Authorization: Bearer ${{ secrets.SENTRY_TOKEN }}" \
            | jq '.error_count')

          if [ "$ERROR_COUNT" -gt 100 ]; then
            echo "High error rate detected: $ERROR_COUNT"
            echo "should_rollback=true" >> $GITHUB_OUTPUT
          fi

      - name: Rollback if errors detected
        if: steps.check.outputs.should_rollback == 'true'
        run: |
          # Get the last deployment ID
          LAST_DEPLOYMENT=$(curl -s https://api.pandastack.io/v1/projects/${{ secrets.PROJECT_ID }}/deployments \
            -H "Authorization: Bearer ${{ secrets.PANDASTACK_TOKEN }}" \
            | jq -r '.data.deployments[1].deploymentId')

          # Rollback
          curl -X POST https://api.pandastack.io/v1/projects/${{ secrets.PROJECT_ID }}/deployments/$LAST_DEPLOYMENT/rollback \
            -H "Authorization: Bearer ${{ secrets.PANDASTACK_TOKEN }}"

This runs every 5 minutes. If the error count exceeds a threshold, it rolls back to the previous deployment automatically.

What happens to the broken deployment after rollback

The broken deployment stays in the history. You can re-rollback to it later (if you fix the bug and want to test it), or you can delete it:

curl -X DELETE https://api.pandastack.io/v1/projects/<project-id>/deployments/dep_123 \
  -H "Authorization: Bearer $PANDASTACK_TOKEN"

This frees up storage (deployments count toward your plan's retention limits).

Using pandastack.json to standardize deploys

To avoid env var mismatches, define them in pandastack.json:

{
  "type": "static",
  "name": "solidjs-app",
  "buildCommand": "npm run build",
  "outputDir": "dist",
  "env": [
    {
      "key": "PUBLIC_API_URL",
      "description": "Backend API endpoint",
      "value": "https://api.example.com"
    }
  ]
}

Now every deploy uses the same env vars, reducing the chance of a broken deploy due to missing configuration.

What you've learned

Rollback is a deployment operation, not a Git operation. It redeploys a previous version's compiled assets without rebuilding from source. Use it to recover from broken deploys quickly, then fix the issue and push a new commit.

PandaStack keeps deployment history for 10/30/90 days (Free/Pro/Premium). Within that window, rollback is instant. Beyond it, you'd redeploy from the Git commit, which takes longer (full rebuild).

The platform purges the CDN cache on rollback, so users see the old version within seconds. No DNS propagation, no stale assets, no waiting for cache TTLs to expire.

For production apps, combine rollback with preview environments and automated testing. Deploy to a preview first, test it, then promote to production. If something slips through, rollback is your safety net.

References

• [SolidJS deployment guide](https://www.solidjs.com/guides/deployment)
• [Vite production build](https://vitejs.dev/guide/build.html)
• [PandaStack deployments API](https://docs.pandastack.io/api/projects/)
• [PandaStack static sites](https://docs.pandastack.io/projects/static/)