Deploying

Four ways to trigger a Pulsar deploy: push-to-GitHub, dashboard button, CLI, or a deploy hook URL.

Push to deploy

When you connect a GitHub repo, Pulsar registers a webhook. Every push to your configured branch triggers an automatic build. This can be disabled per-project in Automations → Auto-deploy on push.

Manual deploy

Click the Deploy now button on the project page, or trigger via the API:

POST /api/projects/:id/deploy

CLI deploy

pulsar deploy                   # uses pulsar.json in current dir
pulsar deploy --project my-app  # explicit project
pulsar deploy --no-wait         # don't wait for completion

Deploy hooks

A deploy hook is a secret POST URL. Call it from GitHub Actions, Zapier, a cron job, or any script to trigger a deploy without needing authentication.

curl -X POST "https://api.pulsardeploy.com/api/projects/ID/deploy-hooks/HOOK_ID/trigger?secret=SECRET"

Create and manage hooks in Project → Automations → Deploy hooks. The secret is part of the URL — treat it like a password.

PR preview deployments

Every pull request gets a unique preview URL based on the PR branch. The preview runs on a separate port with the same build config as production. When the PR is merged or closed, the preview container and URL are automatically cleaned up.

View all active previews in Project → Previews tab. Click Promote to production to re-deploy that exact commit to the main branch.

Rollbacks

Every deployment is immutable. Previous containers are preserved so you can roll back instantly.

# Via CLI
pulsar rollback my-app

# Via dashboard
# Open Deployments tab → any past deployment → Rollback

Auto-retry on failure

Enable Automations → Auto-retry on failure to automatically queue a single retry when a deployment fails. Pulsar checks that no retry has run in the past 10 minutes before queueing, preventing runaway loops. The retry is visible in the deployment history as auto_retry.

Build configuration

Pulsar auto-detects your framework via Nixpacks. Override any setting in the project configuration panel:

Framework:        auto-detected (nextjs, react, vue, svelte, express, fastapi, django, static)
Install command:  npm install   (override with any package manager)
Build command:    npm run build (or skip for static sites)
Output directory: .next         (framework-dependent)
Root directory:   ./            (monorepo support — point to subdirectory)
Branch:           main          (any branch)

Deploy statuses

queuedWaiting in the build queue

buildingDependencies installing, project building

deployingContainer starting, nginx configuring

liveDeployment is live and serving traffic

failedBuild or deploy error — check logs

cancelledManually cancelled before completion

rolled_backReplaced by a more recent deployment or rollback

What happens during a deploy

1.  GitHub push (or manual trigger)
2.  Build queued — assigned a port
3.  Repo cloned at specified branch/commit
4.  Framework detected via Nixpacks
5.  Dependencies installed (npm install / pip install / etc.)
6.  Project built (npm run build / next build / etc.)
7.  Docker image created
8.  New container started on allocated port
9.  Nginx reverse proxy configured
10. Health check passes → deployment marked "live"
11. Old container stopped, rolled_back status set
12. SSL certificate provisioned via Certbot (async)