What the Docker Compose File Defines for an AI Product
A Docker Compose file for an AI SaaS product typically defines several services: a PostgreSQL database (with the pgvector extension for vector search), a Redis instance for caching and queuing, an Ollama service for local LLM inference during development (so API costs are not incurred for every local test run), and sometimes a local Minio instance to emulate AWS S3 for file storage development. Each service is pinned to a specific image version to ensure consistency. Volume mounts ensure that database data persists between Docker Compose restarts, so developers do not lose their test data every time they restart the stack. SpeedMVPs writes the Docker Compose file alongside the application code and tests it on both macOS (Apple Silicon) and Linux to ensure it works across the team's machines.
Ollama for Local LLM Development
Running LLM calls against the actual OpenAI or Anthropic API during local development has real costs that add up across a development team working on AI features. Ollama, included as a service in the Docker Compose file, allows local inference using open-source models (Llama 3.2, Mistral, Phi-3) that are compatible enough with the OpenAI API format that your application code can switch between them and the production API via an environment variable. Development environment variables point the LLM client at the local Ollama instance; production environment variables point at OpenAI or Anthropic. This approach reduces development API costs significantly and also allows offline development. For features where the quality difference between Llama 3 and GPT-4o matters for UI testing, developers can switch back to the production API temporarily via the environment variable.
Environment Variable Management
Docker Compose integrates with .env files for environment variable management. SpeedMVPs provides a .env.example file that lists every required environment variable with placeholder values and a comment explaining what each variable is. Developers copy this to .env and fill in their own API keys. The .env file is in .gitignore so real credentials are never committed. The Docker Compose file references the .env variables and passes them to the appropriate services, so the database URL, Redis URL, and LLM API key are consistent across the application and the Docker services without manual duplication. CI/CD environments use the repository's GitHub Actions secrets rather than .env files, with the same variable names to ensure environment parity.
pgvector Setup in Docker for RAG Development
PostgreSQL with the pgvector extension is the most common vector database choice for AI MVPs at SpeedMVPs, and getting it running locally requires an image that includes the extension. SpeedMVPs uses the ankane/pgvector Docker image (or the pgvector/pgvector image for newer versions) in the Docker Compose PostgreSQL service, which includes pgvector pre-installed. This means developers can run vector similarity search queries locally against the same PostgreSQL version as production without manual extension installation. Database migrations (using Prisma Migrate or Drizzle Kit) run against the local Docker PostgreSQL instance, so schema changes are testable locally before being applied to staging or production.
Developer Experience and Onboarding
With Docker Compose, the onboarding process for a new developer on an AI product reduces from two days of environment setup to approximately 30 minutes: clone the repository, copy .env.example to .env and fill in API keys, run docker compose up -d to start the services, run pnpm install, run the database migration command, and start the development server. This predictable onboarding experience is documented in the project README and SpeedMVPs tests it at the end of the project to ensure it works from a clean checkout. For AI products where the team will grow post-MVP, this onboarding investment pays back immediately with the first new hire.
Docker Compose vs Full Docker for Production
Docker Compose is a development and local testing tool. SpeedMVPs explicitly does not use Docker Compose as a production deployment mechanism: it lacks health checks, automatic restarts, rolling deployments, and the resource management features needed for production reliability. Production services run on AWS ECS, Railway, or Kubernetes with proper container orchestration. However, the Dockerfiles written for Docker Compose services (if any application services are containerised locally) are the same Dockerfiles used in production, ensuring the local container environment matches production. This development-production parity is a core principle of reliable software delivery.