A single node swarm is incredibly simple to setup:

    docker swarm init
    docker stack deploy -c docker-compose.yml

Sure, you could use compose; but it's like using a brick for a nail instead of a hammer. Swarm is just a better tool for Production deployments, and compose is better for development - and since it's so simple on a single node, there's no reason not to, and then you're better setup for multi-node and the best practices surrounding it down the road.

As another commenter mentioned - there's often confusion on using Docker in development vs. production. I think this comes up a lot since people always talk about how "Use the same image everywhere!" when that's not always the case. In development you may be using bind-mounts and attaching your working directory into the container so you can actually edit your files, you may be running the application with nodemon (Or your langauge-equivalent) to monitor changes, or do whatever it is your application needs, maybe you have separate Dockerfile's as you want a more slimmed down Production image. But the idea is more that you bring the dev/production parity closer not necessarily identical. You can now ensure all your developing teams are using the same version of your language, and that things are configured exactly the same, and when you do go into Production - that when the image is built, it will run exactly the same on your CI server as it does in on your Production node. It allows for more consistency. But things aren't necessarily 100% the same between development and production.

Nothing at all, as long as you don’t mind the unreliability of a single server. (I am the author of Compose.)

Honestly though, I would probably use Heroku for deploying little apps like this. The Compose CLI’s sweet spot is development environments.

Edit: There are even official docs for this https://docs.docker.com/compose/production/

I see Docker for production and Docker for development as two different worlds. I think containers can work well for everyone in development. Not everyone needs to use it in production. If you are using Docker Compose for production, then you might not need the advantages of Docker for production (even though it's still useful for development.) If you Google around for production setup of applications, you'll see what a typical flow looks like. I think key points are automation and spreading your resources. Docker compose doesn't address these points.