Named Subsets of Services in Docker Compose — Organize Your Stack Like a Pro

When you work with Docker Compose in real-world applications, you often deal with multiple services: backend, frontend, database, cache, etc.

But what if you don’t always need to run all the services? What if you want to test only the backend or rebuild just the database?

That’s where Named Subsets of Services come in handy.

In this blog, you’ll learn:

• ✅ What named subsets are
• 🚀 Why they’re useful
• 🔧 How to define and use them with examples
• 🧠 Best practices to follow

Let’s dive in!

📦 What Are Named Subsets of Services?

A named subset of services allows you to define a group (subset) of services in your Docker Compose project and run only those services when needed — without spinning up the entire stack.

This is super useful in large, modular apps where you might want to:

• Only test your API (backend)
• Only bring up the database and cache
• Run the frontend in isolation

🔍 Why Use Named Subsets?

✅ Faster Dev Cycles

You don’t have to wait for all services to build/start if you're only working on one.

✅ Better Resource Management

Reduces CPU/memory usage during development or testing.

✅ Simpler Debugging

Narrow down issues without unrelated containers running in the background.

🛠️ How to Use Named Subsets in Docker Compose

You can define subsets manually by passing service names in your docker-compose commands.

📁 Example docker-compose.yml

version: "3.9"

services:
  backend:
    build: ./backend
    ports:
      - "8000:8000"

  frontend:
    build: ./frontend
    ports:
      - "3000:3000"

  db:
    image: postgres:14
    environment:
      POSTGRES_PASSWORD: example

  redis:
    image: redis:alpine

Now you have 4 services: backend, frontend, db, and redis.

🚀 Run a Named Subset of Services

Let’s say you only want to start the backend and database.

docker-compose up backend db

You can also use --build if you want to rebuild just these two:

docker-compose up --build backend db

Or just build them:

docker-compose build backend db

Want to test only the frontend?

docker-compose up frontend

Need to start Redis alone for testing cache?

docker-compose up redis

✨ Pro Tip: Use Override Files for Groups

To manage subsets better, create override files like:

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up backend db

This way, you can define different sets of services in different files (e.g., dev, test, prod) and reuse them easily.

📁 Example: docker-compose.dev.yml

services:
  backend:
    environment:
      NODE_ENV: development
  frontend:
    environment:
      NODE_ENV: development

Now you can run:

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up backend

This gives you dev-specific configs without changing your main docker-compose.yml.

🧠 Best Practices

• Name your services clearly (api, web, db, cache) so they’re easy to reference.
• Use subsets during development to speed things up.
• Use separate Compose files for different environments (dev, test, staging, prod).
• Always use --build with subsets when testing build changes.
• Combine with profiles (if using Compose v3.9+) for advanced setups.

🧩 Bonus: Use profiles for Advanced Control

Compose v3.9+ supports profiles, which are a more advanced way to define subsets.

services:
  backend:
    build: ./backend
    profiles: ["api"]

  db:
    image: postgres
    profiles: ["api", "db"]

  redis:
    image: redis
    profiles: ["cache"]

Now run:

docker-compose --profile api up

Only the services in the api profile will start!

📚 Summary

✅ Final Thoughts

Named subsets of services are a simple but powerful trick in Docker Compose that helps you work smarter, not harder. Whether you're working on a monorepo or a microservice-based app, being able to isolate services can save you time, resources, and headaches.

Start using them today — and make your dev workflow feel lighter.