Skip to main content
There is no .flooignore file. floo never uploads your working directory: every build uses committed source from your connected GitHub repository. floo redeploy without --rebuild reuses the previous image. Two standard files decide what the build sees: .gitignore controls which untracked files Git ignores, and .dockerignore decides what the Docker build context includes.

​
How it works

  1. floo downloads the commit’s source from GitHub. Untracked files never reach the build server. .gitignore prevents new matching files from being tracked; it does not remove files already committed.
  2. Each service builds with its own path as the Docker build context, and its Dockerfile must sit inside that directory, unless the service sets dockerfile, which makes the repository root the context. See Monorepos.
  3. Docker applies the .dockerignore at the root of the build context (beside the Dockerfile by default) before sending the context to the builder.
Files you do not commit cannot be built. Files you commit but list in .dockerignore are downloaded but excluded from the image build.

​
Keep large and sensitive files out of git

Add them to .gitignore:
.gitignore
Secrets belong in floo env set, not in the repository. See Environment variables.

​
Trim the Docker build context

.dockerignore is the standard Docker mechanism and works unchanged on floo:
.dockerignore
Put it at the root of the build context. A smaller context uploads faster and keeps COPY . . from dragging local artifacts into the image.

​
Checking the build

The deploy output shows build progress:
If builds are slow, exclude generated artifacts and large files through .gitignore or .dockerignore, and use a multi-stage build so only the built output lands in the final image. See Dockerfiles and the container contract.