Processes

Last updated December 18, 2023

The Processes page shows your application’s runtime and build processes. You can also edit and define your own runtime commands here.

Runtime Processes: These are the processes required for your application.
Build Process: This shows you the build machine the build process is using.

Web process

The web process runs your application. When you add an application, if you do not specify the Start command for the web process, Kinsta attempts to detect it automatically during the first deployment. For example, the start command for a Node.js application may be npm start or yarn start.

You cannot remove the web process, and you can only have one web process per application.

Background worker

A background worker is a process that runs in the background, separate from the main application, and is inaccessible from the internet. Using a background worker for ongoing tasks like processing large data sets keeps these tasks separate from the main application and helps to maintain a good user experience.

This type of process isn’t meant to be run as a one-time job that finishes after a certain amount of time. If a background process finishes after it completes its job, the pod will shut down, restart itself, and repeat the process. For a process that finishes after completing its job, use a cron job process.

Add a Background Worker Process

You can add a background worker when you add an application or at any time in Processes. While there is no limit to the number of background worker processes you can add, each process requires at least one pod to run.

To add a new background worker, click Create process and complete the fields as follows:

Name: The process name; for example, Price calculation.
Type: Choose Background worker.
Start command: The command required to start the process, for example, npm run [process].
Pod size: This determines the CPU and RAM dedicated to the process.
Instances: The number of instances required, up to a maximum of 50. Each instance represents one pod, and the instances all use the same pod size. You cannot define a different pod size for each instance.

You can change the details of any process at any time, including the pod size (vertical scaling) and the number of pods running simultaneously (horizontal scaling). To learn more about changing pod size and other scaling options, see our guide on how to Scale Application Resources.

Click Continue, review the summary and payment method, and then click Confirm to finish creating the new process.

Cron job process

A cron job allows you to schedule a process at a specific interval for your application. This lets you automate repetitive tasks like sending reports or performing maintenance tasks in a timed manner without a continuously running pod.

A cron job process is similar to a background worker, but only launches based on the configured timing and shuts down after finishing the required operation.

Add a Cron Job Process

You can add a cron job when you add an application or at any time in Processes. While there is no limit to the number of cron job processes you can add, each process requires at least one pod to run.

To add a new cron job, click Create process and complete the fields as follows:

Name: The process name; for example, Marketing email scheduler.
Type: Choose Cron job.
Start command: The command required to start the process, for example, npm run [process].
Repeats: Choose how often you want the process to run (every minute, hour, day, week, month, or year). When you choose how often you want the process to run, you can then choose a specific minute, time, day, date, or month — depending on your first selection.
Pod size: This determines the CPU and RAM dedicated to the process.
Instances: The number of instances required, up to a maximum of 50. Each instance represents one pod, and the instances all use the same pod size. You cannot define a different pod size for each instance.

Click Continue, review the summary and payment method, and then click Confirm to finish creating the new process.

Defining Processes in a Procfile

Procfiles define processes from your application’s code and should be committed to your repository. A Procfile contains one process per line in the following format:

process_name: command

For example, to run a Laravel application, you might want to use the following:

web: php artisan serve --host 0.0.0.0 --port 8080

If you are using a Procfile, you will need to define a process named web to ensure the container will fulfill web requests.

Scaling Application Resources

You can change the pod size of any process (vertical scaling) and change how many pods are run at the same time (horizontal scaling). Any changes you make, except changing the name, automatically trigger the rollout process for the application.

Vertical scaling is great for giving pods more power to complete resource-intensive tasks.
Horizontal scaling is great for resilience and load balancing for applications that process many requests. For example, you could run three versions of the same pod. The underlying technology routes requests to one of the three pods, effectively distributing the load between them. If one pod becomes unstable, requests will route to the other two until the third pod is healthy again.

You can change the details of any process, including the Pod size, at any time. If your application is stateless (no persistent storage), you can enable automatic horizontal scaling for the web process. This lets you set a minimum and maximum number of instances (up to 10) that the process can scale between as needed. To learn more about changing pod size and other scaling options, see Scalability.

Update Build Process Resources

To change the resources used for the build process, click Update build plan, choose the required Build resources, and click Update build.