The Processes page shows your application’s runtime and build processes. You can also edit and define your own runtime commands here. Check out our weather logger example application to see a detailed example of configuring a process.

Runtime Processes

These are the processes required for your application.

Process Types

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 process runs in the background, separate from your main application. Background worker processes are ideal for long-running tasks like generating reports or processing large amounts of data. 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.

There is no limit to the number of background workers you can add; however, each process requires at least one pod to run.

Cron job process

With a cron job process, you can schedule a process at a specific interval for your application so you can automate repetitive tasks. Similar to a background worker, each cron job process requires at least one pod to run but only launches based on the configured timing and shuts down after finishing the required operation.

Defining Processes in MyKinsta

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

  • Name: The process name, for example, “Worker.”
  • Type: Background worker.
  • Start command: The command required to start the process, for example, npm run [process].
  • Pod size: Choose 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.

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).

  • 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 a lot of requests. For example, you could run 3 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. Any changes you make, with the exception of the name, automatically trigger the rollout process for the application. To learn more about changing pod size and other scaling options, see How to Scale Application Resources.

Build Process

This shows you the build machine the build process is using. Clicking Update build allows you to change the resources used for the build process.