Why this exists (aka desperation-driven development)
After fighting with various RCON setups in CI/CD, Docker Swarm and GitOps workflows, I finally gave up and created my own lightweight RCON client as a Docker image.
The main problem I wanted to solve:
long-running RCON sidecars- keeping RCON credentials alive 24/7
- insecure setups where RCON is always reachable
- ugly shell hacks inside pipelines
So this image is intentionally one-shot & stateless.
It runs only when needed, sends a command, exits.
No daemon. No open socket sitting around.
What it is
- Tiny UDP RCON client (Quake 3 style packet format, used by FiveM)
- Docker-first
- Designed for:
- CI/CD pipelines (GitHub Actions / GitLab CI)
- GitOps workflows
- Docker / Docker Swarm / Kubernetes Jobs
- No dependencies, no runtime overhead
What it is NOT
- Not a replacement for in-game admin tools
- Not a persistent RCON service
- Not meant to be exposed publicly
This is automation glue, not an admin panel.
Typical use cases
- Scheduled server announcements
- CI-triggered admin commands
- Controlled restarts / kicks
- Maintenance messages
- GitOps-driven server operations
All without keeping RCON permanently online.
Links
- Docker Hub:
factycz/fivem-rcon-client - Docker Image - GitHub:
GitHub - Facty-cz/fivem-rcon-client: Simple cron client for FiveM server
If someone already solved this in a cleaner way — I’d love to see it.
Otherwise maybe this helps someone who’s also tired of duct-taping RCON into pipelines 
Feedback welcome.