Procfile generator — web, worker and release processes for Heroku

How to use the Procfile generator

1. In Processes, write one line per process type: the name, a colon, then the command, for example worker: node dist/worker.js.
2. Use letters, digits, hyphens or underscores for names. web is the only type that receives HTTP requests.
3. Make the web command use $PORT, or make sure your app reads the PORT variable itself.
4. Read the warnings under the output, fix the lines they mention, and save the result as Procfile in the app root.

What it does and when to use it

A Procfile tells Heroku, and tools that copy its approach, which processes to start for your app. Each line becomes a separate process type that you can scale on its own: more web dynos for traffic, more workers for a job queue. The format is simple, but a typo in a name or a server bound to a fixed port causes failed deploys that are hard to read in the logs.

The .env example generator documents the variables those processes need, and the Makefile generator gives developers the same commands locally. If you deploy with containers instead, the Dockerfile generator plays the same role.

How it works

Each line is split at its first colon into a type and a command, so commands may contain more colons, such as app:app or 0.0.0.0:$PORT. Lines starting with # are skipped. The tool then checks:

• the type uses only letters, digits, - and _, otherwise the line is dropped with a warning;
• the command is not empty, otherwise the line is dropped;
• a web command mentions $PORT or ${PORT};
• no type appears twice.

The format is described in Heroku’s Procfile documentation.

Worked examples

The Node sample:

web: node dist/server.js --port $PORT
worker: node dist/worker.js
release: npx prisma migrate deploy

Two common mistakes. web: npm start and bad type: x give a file with only web: npm start, plus two warnings: “The web process must listen on the port in $PORT” (fine if your app reads PORT itself) and that “bad type” is not a valid process type.

A Python app. web: gunicorn app:app --bind 0.0.0.0:$PORT, two worker lines and an empty clock:. The gunicorn line passes, clock is dropped because it has no command, and the tool warns that “worker” appears more than once.

Empty input returns “Add at least one “type: command” line, e.g. web: npm start”.

Limits and tips

• When a type appears twice, only the last line is kept in the output (here worker: rq worker). If you need both processes, give them different names (for example worker-mail).
• The tool cannot tell whether a command works. Run it locally with the same environment first.
• Keep secrets out of the Procfile; set them as config variables on the platform.