Skip to main content
There is no .flooignore file. floo never uploads your working directory: every deploy, whether a git push or floo redeploy, downloads the commit from your connected GitHub repository and builds from that. Two standard files decide what the build sees: .gitignore decides what is in the commit, and .dockerignore decides what the Docker build context includes.

​
How it works

  1. floo downloads the commit’s source from GitHub. Anything excluded by .gitignore is not in the repository, so it never reaches the build server.
  2. Each service builds with its own path as the Docker build context, and its Dockerfile must sit inside that directory.
  3. Docker applies the .dockerignore next to that Dockerfile 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:
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:
Put it beside the service’s Dockerfile. A smaller context uploads faster and keeps COPY . . from dragging local artifacts into the image.

​
Checking the build

The deploy output shows the build progress:
If builds are slow, check that generated artifacts and large files are excluded 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.