Skip to main content
A Node.js application fits Springwinter’s web server resource when it accepts HTTP traffic and can run in a container. Springwinter builds the image from GitHub, runs it on AWS ECS in your account, and connects it to a public HTTPS endpoint. Updated October 9, 2026. The shortest production path is GitHub repository, Dockerfile, health endpoint, environment variables, then Deploy.

Prepare the application

Listen on 0.0.0.0 and read the port from PORT. Add a lightweight endpoint that does not depend on slow external services.
Graceful shutdown matters because ECS replaces containers during deployments and maintenance. The process should stop accepting requests, finish active work, and exit before forced termination.

Add a production Dockerfile

Pin a supported Node.js LTS version. Install dependencies in a build stage and run as a non-root user.
Use exec-form CMD so Node receives signals directly. Do not put secrets in the image.

Deploy with Springwinter

1

Connect AWS and GitHub

Connect the AWS account that will own the infrastructure, then install the Springwinter GitHub App for the repository.
2

Create a web server

Open a project, click Add resource, and choose Web server.
3

Choose source and compute

Select the repository and branch. Choose CPU and memory based on measured load, not guesses.
4

Configure health and environment

Set the health path to /healthz. Add NODE_ENV, application configuration, and service URLs as environment variables.
5

Deploy and verify

Deploy, open the generated HTTPS URL, inspect CloudWatch-backed logs, and confirm CPU, memory, requests, and errors under Metrics.

Production checklist

  • Commit lockfiles and use npm ci for reproducible builds.
  • Keep request handlers stateless; place durable data in a database or S3.
  • Send logs to stdout and stderr.
  • Set explicit request, database, and outbound HTTP timeouts.
  • Test shutdown during active traffic.
  • Enable auto-deploy only on the branch that should reach production.
  • Use previews for branch-level validation before merging.

Common deployment failures

A health check fails when the server binds only to localhost, listens on the wrong port, or performs expensive dependency checks. An out-of-memory restart usually means the selected memory is too small or the process has an unbounded cache. A deployment that never exits often runs through a shell wrapper that does not forward SIGTERM.

Frequently asked questions

No. A Dockerfile gives you the clearest and most reproducible deployment. Springwinter builds the container from your GitHub source and runs the resulting image on ECS in your AWS account.
Configure secrets and service URLs as runtime environment variables. Never commit secrets to GitHub or copy them into a Docker image layer.
Yes, when the repository’s Dockerfile copies the correct workspace and produces one runnable image. Keep the Docker build context small and make the target service explicit.

Sources and further reading

Last modified on October 8, 2026