Is Docker Swarm suitable for production deployment of a B2B microservice application with moderate traffic?

We are in the phase of deploying a microservice-based application and are currently considering Docker Swarm as our container orchestration solution.

Our constraints:

  • We have limited infrastructure resources (small team, small server footprint).

  • The application is B2B, so the expected traffic is not heavy (moderate load compared to large B2C systems).

  • We want to balance ease of setup/maintenance and production stability.

My questions are:

  1. Is Docker Swarm still a good choice for production environments in 2025, given our use case?

  2. Are there known limitations (scaling, ecosystem, observability, HA) that we should worry about?

Any insights from people who have used Docker Swarm (or migrated away from it) in similar small-scale production setups would be helpful.

Sure, it works. We run multiple small SaaS solutions on Docker Swarm with Traefik reverse proxy, self-hosting on some dedicated servers and cloud VMs.

Not much development happening with Swarm, some bug fixing, no new features. But that has the advantage that it just works, no need to adapt to new APIs or changing config.

One of the challenges is running Postgres in HA, as former standard Spilo seems not really maintained anymore, everything seems to move to cloudnative-pg, which requires k8s. MongoDB cluster runs fine.

Hint when starting: make sure to manually set a larger netmask for your overlay network(s), or you can only have 255 overall Swarm service instances.

I didnt understand what do you mean by the last part (hint)

I’m not a swarm user so @bluepuma77 can confirm, but try running

docker network inspect ingress

You will see the default swarm ingress network is 10.0.0.0/24 24 means you can only use the last segment so you could have values from 0 to 255. Including broadcast, network and gateway IPs. So if you have many services and each get’s an IP, you will run out of free IPs. It is not just a Swarm “issue”. You would need to configure the network in Kubernetes as well.

Related Docker documentation: https://docs.docker.com/engine/swarm/networking/#using-custom-default-address-pools

By the way, as far as I know, Docker is focusing on Development environments currently, not Swarm, so if you need more than open source community support, you would probably want to check the offer of Mirantis which bought the Enterprise part of Docker years ago

Just in, maybe it’s a good time to look for k8s alternatives :sweat_smile:

we have private subnet 10.1.0.0/24 (vm get ip address from that range)

so what should be the subnet that should use docker swarm so we dont have overlap (what is the default subnet used by docker swarm)

Your subnet collides with the default subnet Swarm uses, which is 10.0.0.0/8, see:

https://docs.docker.com/engine/swarm/swarm-mode/#configuring-default-address-pools

docker swarm init
–advertise-addr <MANAGER_IP>
–default-addr-pool 172.20.0.0/16
–default-addr-pool-mask-length 24

is this that subnet will work since it doesnt overlap with 10.1.0.0./24

Is it safe to assume that you tried it by now?

I am not sure if the address pool you choose conflicts with the default address pool docker uses for the bridge networks. If you don’t use bridge network, I assume it should be fine.

I think Docker can recognize already existing networks , so it should only be a problem if the Docker bridge is manually configured to use the colliding IP range or if it already existed before changing the Docker Swarm address pool. I don’t know if Docker Swarm would allow that.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.