Deployments

ServerChirp deploys Git-backed applications into versioned releases. Build work and pre-activation hooks run away from live traffic, then ServerChirp atomically moves the application's current link to the prepared release.

Deployment flow

A typical release moves through these stages:

1. Fetch the selected repository revision.
2. Compose or link the environment and persistent paths into the release.
3. Install dependencies, build the application, and run pre-activation hooks such as database migrations.
4. Verify the built artifact when the stack defines one.
5. For a managed Node.js, Bun, or Laravel Octane runtime, start and probe a candidate process before promotion.
6. Atomically activate the release and promote its managed runtime, when present.
7. Run post-activation hooks and the configured HTTP health check.
8. Prune old releases only after the health check succeeds.

The exact stages depend on the application type and its saved deployment configuration.

The configured deployment HTTP health check runs after activation. If it fails and an earlier retained release is available, ServerChirp attempts to restore that release. Database migrations and other external side effects are not reversed.

Hooks

Add, edit, delete, reorder, reset, and copy hooks. Each hook has a phase, working directory, and optional file condition. User-authored commands are tokenized and executed as the application user; they are not interpolated through bash -c.

php artisan migrate --force
php artisan optimize
php artisan queue:restart

Use pre-activation hooks for work that must succeed before traffic moves. Post-activation hooks run after the current link has changed, so reserve them for follow-up work that is safe to run after the new release becomes live.

Build and runtime settings

ServerChirp can detect or pin npm, pnpm, Yarn, or Bun. Monorepos can define a workspace root, application root, and output directory. Runtime settings include the start command, health path and accepted status codes, startup timeout, restart policy, stop signal, graceful-drain timeout, and resource limits.

Push-to-deploy

Enable push-to-deploy to create a deployment when the selected GitHub branch changes. A deployment is tied to the revision and configuration snapshot it started with, so later edits do not silently change an in-flight run.

Cancellation and rollback

You can cancel a deployment only while it is still pending. Once execution has started, its current run cannot be cancelled from ServerChirp.

Rollback reactivates a retained successful release. A rollback does not reverse database migrations or external side effects, so deployment scripts should keep schema changes backward compatible.

Treat rollback as application-code recovery, not as a substitute for database backups.