How to expose a Docker application safely
A container is not a security boundary. Reduce ports, privileges, secrets and networks, and publish only a controlled entry point.
A common deployment mistake is publishing every port declared by a Compose stack. The Internet should reach one controlled entry point, while databases, queues and administration ports stay on private networks.
Security spans the host, runtime, images, secrets, network and application. Running a process in a container cannot compensate for an unsafe configuration.
Minimise network exposure
Publish only the reverse proxy on 80/443. Use expose rather than ports for internal services and a separate Compose network that is not reachable from the host network.
- Do not publish PostgreSQL, Redis or debug dashboards.
- Restrict admin interfaces through VPN or source allowlists.
- Verify the result from an external network.
Constrain the container
Run as a non-root user, drop capabilities, use a read-only filesystem and tmpfs. Mount only required paths and never give the application the Docker socket.
Updates, backups and visibility
Pin image versions, scan dependencies and test before rollout. Keep data backups off-host, rehearse recovery and monitor the application and certificate externally.
- A healthcheck is not external monitoring.
- Retain the previous image for rollback.
- Alert on failed authentication and state changes.
Before publishing Compose
- Only 80/443 are public.
- Databases and helpers use private networks.
- Containers are non-root and cannot access the Docker socket.
- A backup was restored in a test.
- TLS, updates and monitoring are active.
Put it into practice
Explore N3X Docker apps
Compare requirements, Compose files and managed hosting for self-hosted N3X applications.
Explore N3X Docker appsFrequently asked questions
Does one configuration fit every environment?
No. Inventory traffic, dependencies and the threat model first, then tighten controls. Verify each change externally and keep a rollback plan.
Where should I start?
Start with a tested backup, current patches and a smaller public attack surface. Then add monitoring and document an owner for every service.
How often should I repeat the review?
After every infrastructure or major-version change and at least quarterly. Monitor critical dependencies, certificates and backup outcomes continuously.