Scaling & Procfile
Slasha uses a standard Procfile to define the different application process types running inside your containers, allowing you to scale them independently.
The Procfile Format
Place a file named Procfile (no file extension, capital 'P') in the root directory of your repository. Each line defines a process type and the command to run it:
web: npm run start
worker: npm run queue:work
release: npm run db:migrateSupported Process Types
Slasha recognizes three specific process types, each with its own runtime behavior:
1. web
The entry point for HTTP traffic. Slasha monitors containers running the web process type and automatically registers them with the Caddy reverse proxy. Incoming traffic is distributed across all running web instances.
2. worker
Background processes, queue consumers, and cron task listeners that run continuously but do not receive direct HTTP traffic from the proxy.
3. release
A temporary process that runs exactly once during the deployment phase, before the new web and worker processes are activated.
release process exits with a non-zero status code, Slasha will abort the deployment, clean up the temporary release container, keep the previous version running, and report a deployment failure.Scaling Instances
You can scale the number of active web or worker containers for any application using the dashboard or CLI. By default, Slasha provisions 1 instance of each defined process type.
To scale process counts from the CLI, refer to the slasha scale CLI command reference. When scaled, Slasha starts or stops process containers in parallel, runs health checks on them, and dynamically updates the Caddy reverse proxy routing.
web process count is locked to a maximum of 1. This ensures strict single-writer access to the SQLite database. Attempting to scale beyond 1 while backups are enabled will fail.Process Restart Behaviour
All web and worker containers are provisioned using Docker's unless-stopped restart policy. This means if a process crashes, or the host machine reboots, the Docker daemon will automatically attempt to restart the container indefinitely until you manually stop the app or push a new deployment.