What do the web, worker, release, and clock process types do?

web is the only process that receives HTTP traffic and must listen on the $PORT Heroku assigns. worker runs continuously in the background for jobs and queues. release runs once before every deploy completes, which is the standard place for database migrations. clock is a long-running process for scheduling recurring tasks. You can also add a custom type with any lowercase name, such as scheduler.

Why does the audit warn that my web command ignores $PORT?

Heroku assigns each web dyno a port at runtime and exposes it as the $PORT environment variable. If your start command binds to a hardcoded port instead, Heroku's router cannot reach it and the dyno fails its health check. The audit checks the web command for a $PORT reference and warns when it is missing — for example, gunicorn app:app should become gunicorn app:app --bind 0.0.0.0:$PORT.

Do I need the app.json manifest?

app.json is optional. Its main purpose is enabling a one-click Heroku Deploy button: the manifest describes the app, buildpacks, addons, env vars, and dyno formation so others can spin up a copy. If you deploy with git push heroku main you only need the Procfile, but the generator keeps app.json on by default since it is harmless to include. You can switch the output toggle to view either file.

What is the dyno formation and how does it map to app.json?

The formation declares, per process type, how many dynos to run and at what size (eco, basic, standard-1x, standard-2x, performance-m, or performance-l). It is written into app.json under "formation" as { quantity, size } for each type, so a one-click deploy starts your app already scaled. The audit flags a formation entry whose type has no matching process in the Procfile.

Can I load an existing Procfile to edit it?

Yes. Paste your current Procfile into the "Load an existing Procfile" box and the builder replaces its rows with the parsed processes, classifying web, worker, release, and clock as canonical types and anything else as a custom type. From there you can edit commands, add an app.json, reorder processes, and run the audit before committing changes.

Where do the generated files go?

The process definitions go in a file named exactly Procfile, with no extension, at the root of your repository — the download already uses that name. If the app.json manifest is on, save it alongside as app.json in the same root directory. Both outputs are also encoded in the page URL as you work, so copying the share link reproduces your exact setup for a teammate or a ticket.

Heroku Procfile Generator

Build a Heroku Procfile and a matching app.json visually. Add process rows (web, worker, release, clock, or custom types), configure app.json env vars, addons, buildpacks, dyno formation and a postdeploy script, then read the live output. A built-in audit warns about a missing web process, a web command that ignores $PORT, duplicate types, and risky release commands — and you can paste an existing Procfile to load it straight into the builder.

About this ToolHow it works, benefits & use cases

Most Procfile generators only let you type a couple of lines. This one is a real builder: it models your Heroku app as a set of process rows and emits both a clean Procfile and a matching app.json manifest live as you edit. Add as many processes as you need and pick a kind for each — web (the HTTP server, required and bound to $PORT), worker (a continuous background process), release (a one-off command run before every deploy, ideal for migrations), clock (a scheduler), or a custom type with a name you choose — then type the command that starts it and reorder the rows inline. Toggle the app.json manifest on to also describe the app name, buildpacks, addons, environment variables (with required flags and secret generators), the dyno formation (per-type quantity and size), and a scripts.postdeploy hook. A toggle switches the sticky output between the Procfile and the app.json, a round-trip parser loads an existing Procfile straight into the builder, and an audit panel flags the mistakes people actually ship. The whole setup is captured in a shareable URL for handoff.

How to Use

1Start from a preset (Node web, Web + worker + release, Python/Gunicorn, Rails, or Static) or build from the default web process.
2Add process rows, choose web, worker, release, clock, or a custom type for each, and type the start command.
3Reorder or remove rows with the inline controls; the Procfile updates instantly.
4Turn on the app.json manifest to set the app name, buildpacks, addons, env vars, dyno formation, and a postdeploy script.
5Switch the output toggle between Procfile and app.json, read the audit panel for warnings, then copy or download each file into your repository root.
6To migrate an existing app, paste its Procfile into the "Load an existing Procfile" box to replace the rows with its processes.

Key Benefits

A true process-type builder with reorderable rows, not a two-line text box
Canonical web, worker, release, and clock types plus custom process names
Emits both a clean Procfile and a matching app.json from one model, kept in sync
Full app.json controls: name, buildpacks, addons, env vars, dyno formation, and scripts.postdeploy
Round-trip parser loads an existing Procfile into the builder for editing or migration
An audit panel flags a missing web process, a web command that ignores $PORT, duplicate types, and risky release commands
Five presets covering Node, a full web + worker + release topology, Python/Gunicorn, Rails, and static sites
Runs entirely client-side and encodes the whole setup in a shareable URL

Common Use Cases

Defining the web command for a Node, Python, or Ruby app and confirming it binds to $PORT
Adding a release process that runs database migrations before each deploy
Splitting a web server and a background worker into separate dynos with a formation
Producing an app.json so a repo gets a one-click Deploy to Heroku button
Migrating or auditing an existing Procfile by pasting it into the builder

Procfile

1 process · repository root, no extension

web: npm start

Looks good — a couple of notes

The "web" command does not reference $PORT. Heroku assigns the port via $PORT; binding to a fixed port will fail the health check.

Start from a preset

Process types

The HTTP server — required for web apps and must bind to $PORT

Load an existing Procfile

Paste a Procfile to replace the rows above with its processes.

app.json manifest

Include an app.json manifest

Enables a one-click Deploy to Heroku button.

App name

Description

Buildpacks

Addons

Environment variables

Required

Generate a secret

Dyno formation

No formation set — dynos default to off until scaled.

scripts.postdeploy

Runs once after the app is created from a Deploy button.

Procfile and app.json, kept in sync

Heroku starts your app from a Procfile that maps process types to commands, and an optional app.json manifest powers one-click Deploy buttons. This builder models both from one set of process rows, so the formation and the Procfile never drift apart.

What the audit catches

No web process for an app that should serve HTTP.
A web command that ignores $PORT and will fail Heroku's health check.
Duplicate process types — Heroku keeps only the last one.
A risky release command that re-runs a destructive step on every deploy.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Heroku Procfile Generator

How to Use

Key Benefits

Common Use Cases

Start from a preset

Process types

Load an existing Procfile

app.json manifest

Procfile and app.json, kept in sync

What the audit catches

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Heroku Procfile Generator