Services of a project: web services, workers and scheduled jobs.
Add background workers, scheduled jobs, more web services, databases and Valkey to a project — from its own code, another repository or a ready image — reachable by name and on one bill.
A project is more than one process. Next to the main application you can run a queue worker, a nightly job, a separate API, a database — each as a service with its own resources, all on one bill.
Services are listed on the application's Overview → Services → Add a service. A project can have up to 10 services. The main service must be launched first, and the project's subscription must be active (the trial counts).
Kinds of services
| Kind | What it is |
|---|---|
| Web service | another site or API with its own address |
| Background worker | runs all the time: queues, Horizon, Celery, consumers |
| Scheduled job | starts on a schedule (cron format, UTC), does its work and stops |
| PostgreSQL, MySQL, Valkey | managed databases — see Databases |
Where the code comes from
This project's code
The same code started another way: a queue worker, a scheduler, a WebSocket server (for example Laravel Reverb), a folder of a monorepo, a separate API.
- Command is required — what the service runs, e.g.
php artisan queue:workornode worker.js. - A web service must listen on the port in
$PORT. - A scheduled job also needs a Schedule in cron format (UTC), e.g.
*/5 * * * *. - Every new version of the main service is deployed to these services too, so they always run the same code.
Another repository
A web service or a background worker from a different repository of your connected Git account, with its own branch and, if needed, Project folder and Build and start commands (leave a field empty to use what we detect). It gets its own deploys and versions and deploys every push to its branch. Branch previews are not made for services yet.
A ready image
A web service or a background worker from a ready image (Docker image) on Docker Hub, GitHub Container Registry or any other registry — for example nginx:1.27 or ghcr.io/org/app:tag.
- Port — the port the image listens on; we also pass it in
$PORT. - Command — optional; empty starts the image as it is built to.
- Private registry — a user name and a password or access token. They are stored encrypted, used only to download the image and never shown again.
- With automatic deploys on, we check once a day whether the tag points to a newer version and deploy it. Download the image again on the Deploys tab does it right away.
Reaching each other by name
Services of a project talk over a private network by name: a service called api is reachable from the others as api, a database called db as db, and the main service as web. The panel shows it as «Reachable in the project as «api»». Traffic between services of a project is not counted as traffic.
Every service gets the project's variables — including the database connection — plus variables of its own, which win over the project's. See Environment variables.
Resources and price
Each service has its own Memory, CPU and Disk, priced like any application: $6 per GB of memory and $4 per CPU core a month, with 10 GB of disk included per GB of memory, then $0.15 per GB. A service can have up to 8 GB of memory.
When you add a service, its price is added to the project's bill — for the current month only the remaining part of it. While the project is on its free trial, new services are free until the trial ends.
The Overview shows Project total — what all services of the project cost a month together.
Workers inside the application itself
You don't always need a separate service. The main application's Processes tab has:
- Background workers — up to 5 long-running processes next to the site, e.g. a queue worker. They share the application's resources and restart with every deploy.
- Scheduled commands — up to 10 commands on a schedule (cron format, UTC). Their output is in the log under Schedule.
- Console — run a one-off command inside the running application, with its variables and database. A command can run up to 15 minutes; interactive commands (tinker, a shell) are not supported here.
A separate service is the better choice when a worker needs its own resources, so that a heavy queue never slows the site down.
Changing a service
Open the service from the Services list. Its Settings hold the command, schedule, image or branch, and its resources; changes are saved and the service restarts with them. Each service also has its own Logs and Monitoring.