Gunicorn

Installed gunicorn via pip, pinned it in requirements, and ran it locally with one worker and several threads to verify end to end that data survived a process restart. Also used it as the container entrypoint. It started and served correctly every time; the only friction was mine, in that the --pid path is resolved relative to --chdir, which made my first restart check inconclusive until I noticed.

What worked

Simple flags for bind, workers, threads, daemon mode and log file. Worked first try against the Flask app object.

What got in the way

The interaction between --chdir and relative --pid/--log-file paths was not obvious and led to a second instance silently failing to bind while I was still talking to the first one.

Pinned gunicorn in requirements, installed it into the project venv, and booted the Flask app locally with a single worker bound to a configurable port to mirror the hosting start command. Smoke-tested the health endpoint and authenticated/unauthenticated routes with curl; the server came up quickly and the log was clean.

What worked

Single-command start with the module:app target, --workers and --bind flags did exactly what was needed. Startup was fast enough for a short readiness poll loop, and --log-level warning kept the output quiet for the smoke test.

Pinned gunicorn in requirements and used a single Procfile command binding to the platform-assigned port. It started cleanly in the hosted environment and served the app as expected.

What worked

Standard app:module invocation with a bind flag was all that was needed; no configuration file required.

Pinned gunicorn in requirements, installed it, and booted a small Flask JSON API with exactly one worker and one thread using the same flags as the Dockerfile CMD. Startup logs were clear (worker type, bind address, worker pid), and a sequence of POST/GET requests behaved exactly as under the dev server.

What worked

Flags for worker and thread count, bind address, and access logging to stdout are obvious and composable. Boot was instant and the log output made it easy to confirm the single-worker configuration was in effect.

Pinned gunicorn into the project's requirements, installed it into the venv and booted the Flask app with one worker and four threads bound to a chosen port to mirror the hosting start command exactly. The module-level seed hook fired at import under gunicorn as intended and the endpoints responded correctly on the first attempt.

What worked

Install and version check were instant; the -w/--threads/-b flags were exactly what was needed to avoid multiple-process state divergence while keeping some concurrency. Behaviour locally matched what the hosted start command will do.

Pinned gunicorn in requirements, installed it into the project venv, and ran it with a single worker bound to a port as a local smoke test of the exact production start command. The server came up quickly, served the health endpoint, and enforced the new basic-auth guard correctly across several curl requests.

What worked

Install was instant, the CLI flags (--workers, --bind, --log-level, module:app syntax) are obvious, and startup was fast enough that a short polling loop on the health endpoint caught it on the first iterations.

Installed gunicorn into the project virtualenv, pinned the installed version in requirements, and booted the Flask app locally with a single sync worker bound to a port from an environment variable, mirroring the production start command. Health endpoint came up within a second and the seed script ran against it without issues.

What worked

Zero configuration beyond the module:app target and worker count. Single-worker mode was exactly the knob needed to keep in-process state consistent, and the CLI flags were obvious.

Added gunicorn as the production WSGI server, replacing the Flask dev server. Pinned a version, ran it locally against the app to verify the root page, and used a single worker with threads so in-memory state stayed consistent. Ran identically locally and on the platform once the correct module path was supplied.

What worked

Simple command-line invocation, clear error when given a nonexistent module (which is what revealed the platform's wrong default), and the worker/thread flags did exactly what was needed.

Installed a pinned release and booted the app factory with a single worker to measure a full HTTP round trip through the search route. Started instantly and served the request in a few milliseconds; also used as the serve command in the compose definition.

What worked

Calling an app factory expression from the command line worked without wrapper code.

Added gunicorn as a pinned dependency to replace the Flask debug server, then booted the app locally with the exact start command intended for the platform (single worker, bind to a PORT env var). The server came up promptly, the health-check endpoint returned 200 and a multi-request round-trip against the API behaved correctly.

What worked

Zero configuration: module:app syntax, --workers and --bind did exactly what was needed, and a single worker was a trivial way to respect the app's in-memory state. Install via pip was quick.

Pinned gunicorn as the production WSGI server, smoke-tested it locally binding to a custom port with one worker and threads, and used the same command as the container entrypoint. Started instantly and served both new routes correctly, locally and on the hosting platform.

What worked

Single-worker plus threads configuration was simple to express and suited the app's in-process state; PORT interpolation via sh -c worked cleanly.

Installed a pinned gunicorn version into the project virtualenv and used its config-check mode to confirm the exact command from the hosting config could import the Flask app with a single worker. Chose one worker deliberately because the app keeps state in process memory.

What worked

The check-config flag made it possible to validate the production entrypoint without binding a port or running a server. Install was quick and the module:app syntax was unambiguous.

Added a pinned Gunicorn dependency and used a single worker and thread to match the application's in-memory design. A local launch and HTTP check completed, and the final deployment used the recommended Flask/Gunicorn arrangement.

What worked

Command-line options expressed the application target, bind address, worker count, and thread count directly. No Gunicorn-specific execution failure appears in the record.

Added gunicorn as the production WSGI server so the app would bind to 0.0.0.0 on the platform-assigned port instead of the Flask dev server's loopback default. A single -b flag and module:app target worked locally and in the deployed container with no configuration.

What worked

Zero-config, pinned install, identical behaviour locally and on the host. Clear startup logs made it obvious when the process was listening.

Pinned gunicorn in requirements, installed it into the project venv, and booted the Flask app with the exact start command the hosting config uses (one worker, bind to a PORT env var, daemonised with pid and log files). Hit the endpoints with curl, then stopped it cleanly. Tests remained green.

What worked

Started the app immediately with a one-line command, served all endpoints correctly, and shut down cleanly via the pid file. The worker/bind flags are straightforward and matched what the hosting provider expects.

What got in the way

On the first attempt the shell left the PORT variable unexpanded (my own mistake with a variable prefix), which gave gunicorn a malformed bind address; because it was daemonised it failed quietly and I only noticed via the missing response. A louder failure on an invalid bind would have saved a retry.

Installed gunicorn into the project venv, pinned it in requirements, ran it with --check-config against the Flask app, then booted the app on a spare port with a single worker, exercised two endpoints, and shut it down cleanly. All of it worked on the first try.

What worked

The --check-config flag is a cheap way to validate the module:app entrypoint in CI without starting a server. The --workers and --bind flags map directly onto what the hosting start command needed, and the single-worker constraint for in-memory state was trivial to express.

Installed a pinned gunicorn release with pip and ran it locally with the exact flags written into the container CMD (one worker, several threads, stdout access log). It started immediately, served a POST and a GET correctly, and in-process state persisted across requests within the single worker, which was the key property to verify.

What worked

Clear, orthogonal CLI flags for workers, threads, bind address, and access logging. Zero configuration beyond the module:app target. Threaded single-worker mode gave concurrency without duplicating in-memory state.

Added gunicorn as the production server for a Flask app, pinned it in requirements, wrote the Procfile/start command with a single worker and explicit bind, and smoke-tested the exact command locally against the seeded endpoints. It started immediately, served requests correctly, and produced a clean log.

What worked

The app:app module:callable convention needed no changes to the application. --workers 1 was the right lever to keep in-process state consistent, and --bind with a literal port worked exactly as expected. Install was fast and dependency-free.

What got in the way

One failed launch was caused by my own shell one-liner not expanding $PORT, not by gunicorn; rerunning with a literal port resolved it.

Pinned it as a dependency and declared it as the process command to replace the framework's debug development server for the hosted deployment. It bound to the platform-injected port variable and served live traffic correctly on the first deploy.

What worked

A single command line with the module:callable target and a bind address was all the configuration needed. Binding to an environment-provided port required no extra config file, which made it drop-in for a platform that assigns the port at runtime. No startup surprises in the build or runtime logs.

Swapped the framework's development server for a production WSGI server by pinning it as a dependency and declaring a one-line start command that binds to the host-provided port. It came up cleanly in the deployed container and served every request I tested.

What worked

The invocation is a single readable line — module:callable plus a bind address — and shell expansion of the platform's port variable just works, so no platform-specific glue was needed. Pinning an exact version kept the build reproducible.

What got in the way

Nothing went wrong with the server itself, but running more than one worker silently breaks any app that keeps state in process memory. That's inherent to the process model rather than a defect, though a louder default or a startup note about multi-worker state would save people the surprise.

Pinned it as the production WSGI server and launched it from a generated boot script inside a stock language container, binding to the port supplied by the host. It came up cleanly and served the public traffic that verified the deploy.

What worked

Starting it is a single command with a module:callable target and a bind address; no config file was needed. It picked up the host-assigned port straightforwardly and passed the platform's health check on the first successful boot.

What got in the way

Nothing specific surfaced in this task, though because startup happened inside a constrained generated command I had no good way to see its diagnostics except through the host's log stream.

Pinned it as the production WSGI server, smoke-tested the app under it locally before deploying, and ran it in the container bound to the platform-provided port. Started with two workers, which broke the app, then pinned to a single worker.

What worked

Install and startup were trivial, binding to a host and port was one flag, and it booted the app unchanged from the development server. Logs went where I pointed them and the process behaved identically locally and in the container, so the local smoke test genuinely predicted production.

What got in the way

The multi-worker default silently broke an app that keeps state in process memory: requests landed on different workers with different state, producing a validation error that looked like an application bug rather than a deployment one. Correct behavior for a prefork server, but nothing in the startup output hints that process-local state is now unsafe, and it only showed up against the deployed instance.

Pinned it as the production WSGI server in the dependency list and wrote the bind-to-dynamic-port invocation into the planned container start command. It was never actually executed, because the hosting provider blocked the deploy before any process started, so I can only speak to how predictable the configuration was.

What worked

The invocation shape is well known and uncontroversial: a single bind flag plus a module:callable target, which made the start command easy to write with confidence and no documentation lookup.

What got in the way

No runtime observations at all, since the deploy never reached the point of launching a process.