Bring your own Dockerfile

ScaleBop deploys any repository with a working Dockerfile to ECS Fargate behind an Application Load Balancer — Go, Rust, Ruby, Java, PHP, anything that speaks HTTP. Nothing about ownership changes: your Dockerfile stays in your repository, the image is built by your GitHub Actions workflow, and ScaleBop never builds images itself.

How detection works

ScaleBop’s analysis looks for a Dockerfile in the directory of each deployable app, at the repository root, or as a root Dockerfile.<name> (for example Dockerfile.api). When no app framework is detected, a Dockerfile-backed directory becomes a Dockerfile deployable and follows the container path:

1. Your workflow builds the image from your Dockerfile and pushes it to Amazon ECR.
2. The generated CDK rolls your ECS service out to the new image, with automatic rollback if the new tasks never turn healthy.

Dockerfiles in .devcontainer/, test/ folders and similar non-app locations are ignored.

The two questions we may ask

The generated load balancer needs two things the image cannot always tell us:

• Container port. Read from EXPOSE <port> or ENV PORT=<port> in your Dockerfile’s final stage. When neither is present — or several ports are exposed — ScaleBop asks you to confirm the port (prefilled 8080) before deploying. If the image has no port and starts a background worker or scheduler (Celery, RQ, Sidekiq, cron and similar), ScaleBop says it can’t deploy it: it runs apps that answer web requests behind a load balancer, so run workers and scheduled jobs elsewhere for now.
• Health-check path. Taken from a HEALTHCHECK CMD that curls or wgets a URL. Otherwise ScaleBop health-checks / and accepts any 200–399 response. If / needs auth or redirects, the rollout fails — confirm a path any unauthenticated visitor gets a successful response from (for example /healthz).

You can change both at any time from the plan step; the container settings there override everything ScaleBop detects.

Requirements for the load balancer

Because the ALB forwards to your tasks:

• Listen on the task’s PORT. ScaleBop sets a PORT environment variable to the confirmed port — apps that read process.env.PORT (or the equivalent) just work.
• Bind on 0.0.0.0, not localhost. A server bound to localhost is unreachable from the load balancer. ScaleBop sets HOSTNAME=0.0.0.0 for servers that read it.
• Answer within 60 seconds. CloudFront waits up to 60 seconds for your container to start responding to a request, then returns a 504 to the visitor. Move slow work, such as report generation or long AI calls, to a background job, or stream the response so the first bytes arrive in time.
• Production commands only. A Dockerfile that runs a dev server (npm run dev, --reload, nodemon) passes analysis but fails at rollout. ScaleBop warns when it sees one.

Monorepo build context

docker build normally gets the Dockerfile’s directory as its context. ScaleBop builds from the repository root instead, with -f <dir>/Dockerfile, when any stage of your Dockerfile:

• COPYs files from above that directory (for example COPY ../../shared ./shared), or
• copies a lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock, uv.lock, poetry.lock and so on) that the directory doesn’t have but the repository root does, as in a workspace whose lockfile sits at the root.

The plan step shows the docker build command and the context it uses.

Build arguments

If your Dockerfile declares ARG VITE_API_URL (or any ARG matching a public, browser-bundle prefix like VITE_ or NEXT_PUBLIC_) and you configure that key in ScaleBop, the workflow passes --build-arg NAME="${{ vars.NAME }}" to the build. Keys classified as secrets are never build args — they stay task-level secrets, because anything in an image can be read from the published image.

Task size

Unknown images run on the same Fargate size as Next.js apps (0.5 vCPU / 1 GiB). If your app needs more, that is a change to make in your generated infra/ — ScaleBop tells you when health checks time out.