Docker

Containerizing starts with having the FlutterFlow source code locally. In FlutterFlow, with a Pro plan active, use one of two export paths: click the Download Code button (or find it in the top toolbar menu) to download a ZIP of the entire Flutter project, then unzip it to a folder on your computer like `~/Projects/my-app/`. Alternatively, use Settings → Integrations → GitHub to push the project to a GitHub repository, then clone that repository to your machine. Either way you end up with a standard Flutter project folder — you should see `pubspec.yaml` at the root alongside `lib/`, `android/`, `ios/`, and `web/` directories. Confirm the web/ directory exists (it typically does in FlutterFlow exports as the web platform files are included by default). This folder is where your Dockerfile will live alongside the Flutter source. If you want to verify the build works before adding Docker, open a terminal, navigate to this folder, and run `flutter pub get` followed by `flutter build web --release`. If the build succeeds, you'll see a `build/web/` directory appear. This is exactly what Nginx will serve inside the Docker container. Note: you do NOT need Flutter installed locally to build inside Docker — the build stage handles it — but a local test can catch problems earlier.

A multi-stage Dockerfile solves the image-size problem: the first stage (the builder) uses a large Flutter SDK image to compile your app, and the second stage (the runner) copies only the compiled static files into a tiny Nginx image. Create a new file named exactly `Dockerfile` (no extension) at the root of your Flutter project — the same level as `pubspec.yaml`. The builder stage uses `ghcr.io/cirruslabs/flutter:stable` as the base image (this is a well-maintained Flutter image from the Cirrus CI project). It copies your project files, runs `flutter pub get` to install dependencies, then runs `flutter build web --release` to compile the app. The output appears in `build/web/`. The runner stage starts fresh from `nginx:alpine` — one of the smallest usable web server images. It copies the `build/web/` directory from the builder stage into Nginx's default web root at `/usr/share/nginx/html`. An optional custom `nginx.conf` handles the single-page app routing: Flutter web uses client-side routing, so any URL path should fall back to `index.html` rather than returning a 404. Without this configuration, deep links (e.g., `/profile/settings`) will show an Nginx 404 page instead of loading the Flutter app. The Dockerfile below includes this SPA routing config inline.

1# Stage 1: Build the Flutter web app
2FROM ghcr.io/cirruslabs/flutter:stable AS builder
3
4WORKDIR /app
5
6# Copy project files
7COPY . .
8
9# Install dependencies
10RUN flutter pub get
11
12# Build for web in release mode
13# If your app is served at a subpath (e.g. /app/), add: --base-href /app/
14RUN flutter build web --release
15
16# Stage 2: Serve with Nginx alpine
17FROM nginx:alpine AS runner
18
19# Remove default Nginx static files
20RUN rm -rf /usr/share/nginx/html/*
21
22# Copy compiled Flutter web output from the builder stage
23COPY --from=builder /app/build/web /usr/share/nginx/html
24
25# Add a simple Nginx config for Flutter SPA routing
26# (all paths fall back to index.html so Flutter's router handles them)
27RUN echo 'server { \
28  listen 80; \
29  root /usr/share/nginx/html; \
30  index index.html; \
31  location / { \
32    try_files $uri $uri/ /index.html; \
33  } \
34}' > /etc/nginx/conf.d/default.conf
35
36EXPOSE 80

When Docker reads your project folder to build the image, it copies everything in the directory into the build context. Without a .dockerignore file, this includes generated directories that are large but unnecessary — the `build/` directory from previous local builds, the `.dart_tool/` cache, and `.flutter-plugins`. Including these wastes time and can cause the builder stage to use a cached local build instead of running a fresh `flutter build web` inside the container. Create a file named `.dockerignore` at the project root and add the entries below. Docker will skip these paths when building, making the `COPY . .` step in your Dockerfile faster. The `.dockerignore` syntax is similar to `.gitignore` — each line is a path or glob pattern relative to the project root. After adding this file, your `docker build` will be noticeably faster on subsequent runs because it only sends the source files Docker actually needs to the build daemon.

1# .dockerignore — exclude generated and local-only files from the Docker build context
2build/
3.dart_tool/
4.flutter-plugins
5.flutter-plugins-dependencies
6.packages
7.pub-cache/
8.pub/
9android/.gradle/
10ios/Pods/
11*.log

With the Dockerfile and .dockerignore in place, you can build the image. Open a terminal in your project root (the directory containing Dockerfile and pubspec.yaml) and run the docker build command. Give the image a tag so you can refer to it easily: use `-t my-app:latest` or a more specific name like `my-flutterflow-app:v1`. Docker will execute the two stages: first pulling the Flutter image (large, may take a few minutes on first download), running `flutter pub get`, and running `flutter build web --release` inside the builder container; then starting the Nginx stage, copying the compiled files, and applying the Nginx config. The build stage is the time-consuming part — Flutter web builds can take 2-5 minutes on a cold cache because the Dart-to-JavaScript compilation is heavyweight. After the image is built, run it with `docker run` to verify: map port 8080 on your machine to port 80 inside the container. Open a browser and navigate to `http://localhost:8080` — your FlutterFlow app should load in the browser. Test a few navigations to make sure the SPA routing works (navigate to a sub-screen, refresh the page — it should still load, not show an Nginx 404). If assets are missing or the app shows a blank screen, check the browser console for 404 errors on .js or .wasm files, which usually indicates a --base-href mismatch.

1# Build the Docker image (run this in the project root folder)
2docker build -t my-flutterflow-app:latest .
3
4# Run the container, mapping port 8080 on your machine to port 80 in the container
5docker run -p 8080:80 my-flutterflow-app:latest
6
7# Open http://localhost:8080 in your browser to verify the app loads

Once the image builds and runs correctly locally, tag it with a registry-qualified name and push it so it can be pulled by servers or CI/CD pipelines. The process differs by registry: for Docker Hub, your image tag is `your-dockerhub-username/my-flutterflow-app:latest`; for GitHub Container Registry, it's `ghcr.io/your-github-username/my-flutterflow-app:latest`; for GitLab Container Registry, it's `registry.gitlab.com/your-group/my-app:latest`. Log in to your registry in the terminal using `docker login`, then re-tag the image with the registry-qualified name using `docker tag`, and push with `docker push`. Once pushed, any server with Docker installed can pull and run your app with a single `docker run` command — no Flutter SDK, no build dependencies needed. For CI/CD integration, add the docker build and docker push steps to your pipeline (see the docker CI pipeline example in the code block below). Every FlutterFlow export that triggers a new GitHub commit can automatically trigger a CI build of a fresh Docker image — creating a seamless deploy pipeline from FlutterFlow visual editor to production container.

1# Tag the image for Docker Hub (replace 'yourusername' with your Docker Hub username)
2docker tag my-flutterflow-app:latest yourusername/my-flutterflow-app:latest
3
4# Log in to Docker Hub
5docker login
6
7# Push the image
8docker push yourusername/my-flutterflow-app:latest
9
10# --- On the deployment server ---
11# Pull and run the image (no Flutter SDK needed on the server)
12docker pull yourusername/my-flutterflow-app:latest
13docker run -d -p 80:80 --name flutterflow-app yourusername/my-flutterflow-app:latest