Deploy an app without a Dockerfile

Most apps need no Dockerfile. If yours has none, GetFlowing reads its files, works out the stack, and writes a Dockerfile for it when it builds. It never adds the file to your repository.

The Dockerfile it wrote is printed at the start of the build log. When the deploy goes live, GetFlowing says what it built the app as, for example:

GetFlowing built it as a Next.js app (pnpm, Node 24), with a Dockerfile it wrote as the repository has none of its own; add one to the repository to change how it is built.

A connected AI assistant can find out before anything is built: its check_app says what GetFlowing would build the app as, or why it cannot. To change how your app is built, add your own Dockerfile. See Take over with your own Dockerfile.

The stacks it recognisesCopy Anchor Link

The first stack that matches your app is used, in the order below. A PHP, Ruby, Go, Rust, Java, .NET, Elixir, Gleam or Deno app can also have a package.json, for its front end or its npm packages, and it is still built as its main stack. A Python app that lists Django, FastAPI, Flask, Starlette, gunicorn or uvicorn is built as Python even if it also has a package.json.

Every app it builds runs as a user other than root.

Static sitesCopy Anchor Link

A static site is served as files. A path is served as its file, its .html page or its folder, and anything else gets index.html, so a single-page app's routes work. Files whose names start with .env, .git or .ht, and .npmrc, are never served.

Choosing versionsCopy Anchor Link

GetFlowing reads the version your app asks for, and otherwise uses its default.

The package manager comes from packageManager in package.json, or from the lockfile you commit. Commit your lockfile: the install is held to it, so the versions you tested are the versions that are built.

Choosing the start commandCopy Anchor Link

• Node: a Procfile's web: line, else the start:prod, start or serve script in package.json. A script that only runs a development server is skipped. With none, GetFlowing tries the framework's own server (Next.js, Nuxt, SvelteKit with adapter-node, Astro with @astrojs/node, NestJS), then the main file in package.json, then server.js, index.js, app.js or main.js.
• Python: a Procfile's web: line, else the framework's production server: gunicorn for Django and Flask (uvicorn for a Django app served over ASGI, waitress for Flask), uvicorn for FastAPI. With no framework, python main.py, app.py or server.py, which must then read PORT itself.
• Ruby: a Procfile's web: line, else rails server for Rails, else Puma or rackup on config.ru.
• Deno: a Procfile's web: line, else the start task in deno.json (its preview task where start only watches for changes), else its main module, such as main.ts, server.ts or app.ts, with every permission. An app that serves with Deno.serve or deno serve answers on the port in PORT whatever address it names, and a module that exports a fetch handler is served.
• PHP: Apache, on the port in PORT.
• Go, Rust, Java, .NET, Elixir and Gleam: the program the build made.

Whatever starts your app must listen on 0.0.0.0 on the port in PORT. See What every app needs.

Variables the build readsCopy Anchor Link

A front end reads some variables when it is built, not when it starts, and puts their values into the pages every visitor downloads. When GetFlowing writes the Dockerfile, its build is given your app's variables with the prefix the app's framework reads:

• Only variables not marked secret are given. When you add one, untick Store as a secret.
• A variable marked secret is never given to the build, whatever its prefix. The deploy names any it left out:

NEXT_PUBLIC_API_URL is marked secret, so the build was not given it: a variable with a public prefix is put into the pages every visitor downloads. If it is meant for the browser, unmark it as secret; if not, rename it without the prefix.

• The values are never written into the image's history or the build log. The log names the variables only.
• A changed value reaches the app at its next deploy, which builds it again.
• If these variables come to more than 16 KB compressed, the deploy is refused before anything is built.

With a Dockerfile of your own, the build is given none of your variables. See Variables and secrets.

What an app cannot start withoutCopy Anchor Link

Some frameworks cannot start without a secret that only you can give. GetFlowing finds them from the app's code and asks for them before the deploy:

If the app's variables do not have one, the deploy is refused before anything is built. The message names each variable and what it is for, for example:

GetFlowing builds this as a Laravel app (PHP 8.4), which cannot start without APP_KEY, the key Laravel encrypts sessions and cookies with: run php artisan key:generate --show on your computer and set what it prints, marked secret. Set it in the app's Variables, then deploy again.

Set each one in the app's Settings, under Variables, a key marked secret, then deploy again. GetFlowing compares only the names: it never reads, makes or logs a value. The app's chat says the same before it asks for any approval, and a connected assistant's check_app lists them.

Framework notesCopy Anchor Link

PhoenixCopy Anchor Link

• Where config/runtime.exs reads PHX_HOST, every deploy sets it to the app's address, unless the app's variables set it.
• An app that uses PostgreSQL through Ecto (postgrex in mix.lock) is given a managed database, under the variable config/runtime.exs reads. See Databases.
• Its server is started, and it runs with no Erlang distribution.

DjangoCopy Anchor Link

• Static files are collected when the app is built, where WhiteNoise serves them and STATIC_ROOT is set.
• ALLOWED_HOSTS: the health check asks the app by its own address, which Django refuses unless ALLOWED_HOSTS names it. Where the settings read ALLOWED_HOSTS from a variable as a list, such as os.environ.get("ALLOWED_HOSTS", "").split(","), GetFlowing adds that address when it starts the app (a Procfile that starts it is left as it is). Where the hosts are written into the settings, or read as one host, and do not include "*", the health check fails, and a connected assistant's check_app says so. Read them from a variable as a list instead.

Laravel and RailsCopy Anchor Link

Laravel's APP_KEY, and Rails's RAILS_MASTER_KEY or SECRET_KEY_BASE, are asked for before the deploy. A front end with a build script in package.json is built with Node, and given the variables its build reads.

Apps in a monorepoCopy Anchor Link

A Node app in a folder of its repository, where a workspace at the repository's root names that folder (in the workspaces list of the root's package.json, or the packages of pnpm-workspace.yaml), is built from the repository's root, with the lockfile committed there. The packages it depends on are built first.

A Node app with a lockfile of its own, which takes nothing from a workspace, is built from its folder alone. So is an app of any other stack in a folder.

A workspace's app is refused when:

• There is no lockfile committed at the repository's root.
• It takes a package from a file: or link: path outside the repository.
• It takes packages from a workspace (workspace: or catalog: versions, or a path outside its folder), and no workspace at the root names its folder.
• It takes a package with a workspace: version, and no package of that name is in the workspace's folders.
• Its package.json has no name, and it is built with pnpm, Yarn 2 or later, or Turborepo, which pick it by its name.

Apps it cannot build without a DockerfileCopy Anchor Link

For these apps GetFlowing does not guess. It says why before it builds, and you add a Dockerfile or change the app.

Not covered yetCopy Anchor Link

• Stacks not in the table above. Add a Dockerfile for them.
• Other Elixir, Gleam and Deno releases. Each is built on the one release in Choosing versions. An app that needs a newer one fails its build, and the build log says why.
• Installing one app of a Yarn 1 to 3 or Bun workspace. The whole workspace is installed.
• A Django app whose hosts nothing can be added to. It fails its health check. See Django.

Take over with your own DockerfileCopy Anchor Link

To change how your app is built, add a Dockerfile where GetFlowing looks for one. GetFlowing then builds from yours and writes none. The one it wrote is at the start of the build log, so you can start from that. See Deploy an app with your own Dockerfile.

A Dockerfile of your own is given none of your app's variables while it builds, so a front end that reads them at build time needs another way to get them. See What it does not support.