Self-hosted infrastructure management, honestly reviewed. No marketing fluff, just what you get when you deploy it.

TL;DR

What it is: MIT-licensed self-hosted dashboard that centralizes server management, application uptime tracking, and network visualization in one place [README][4].
Who it’s for: Home lab operators and self-hosters who are already running Uptime Kuma, a server dashboard, and a network diagram tool separately — and want to consolidate [1].
Cost savings: There is no SaaS version to escape. CoreControl is purely self-hosted, MIT-licensed, free to run on any hardware. The cost is a Docker-capable server you probably already own.
Key strength: Simple deployment (three Docker containers, one compose file) covering server inventory, application uptime monitoring, and network topology — without the complexity of Grafana, Prometheus, or Netdata stacks [1][README].
Key weakness: Early-stage project with 1,283 GitHub stars and 34 forks. The dashboard section is explicitly marked “WIP” in the README. No multi-user RBAC, no alerting channels beyond basic notifications, and limited community review coverage to establish long-term reliability [README][4].

What is CoreControl

CoreControl is a self-hosted dashboard for managing server infrastructure. The one-line pitch from its GitHub README: “The only dashboard you’ll ever need to manage your entire server infrastructure.” The reality is narrower than that claim, in both good and bad ways [README].

What CoreControl actually does is four things. It maintains a server inventory with hardware details and quick-links to management panels. It tracks your self-hosted applications and monitors their uptime and downtime history. It generates network flowcharts showing how your services connect. And it exposes a basic system metrics view — CPU, RAM, GPU, uptime, load averages — pulled via a sidecar agent [README][1].

The architecture is a three-container Docker setup: a Next.js/TypeScript frontend, a Go-based monitoring agent, and PostgreSQL for storage. The agent handles metric collection using Glances under the hood, which means the metrics layer is a known quantity rather than custom code [README][1].

The project lives at corecontrol.xyz and the GitHub repository (originally under the name CoreObs, since renamed) shows 383 commits, 13 releases with v1.0.1 as the latest stable, and a Discord community. It is MIT-licensed with no commercial tier — there is nothing to upgrade to, nothing to pay for, no vendor to call [README][4].

As of this review: 1,283 GitHub stars, 34 forks, 10 watchers. By comparison, Uptime Kuma sits at 65K+ stars. This is a young project, which matters when evaluating whether to anchor your infrastructure visibility around it.

Why people choose it

The Virtualization Howto review [1] captures the honest pitch better than the README does: CoreControl is for people who are already running “Uptime Kuma, a dashboard, and other tools” and want one thing instead of three. The reviewer puts it plainly — CoreControl “could effectively assume the role of multiple applications in the home lab.”

That consolidation argument is the whole case for CoreControl. Not that it does any one of those things better than the dedicated tool, but that it does all of them adequately without requiring you to maintain Grafana + Prometheus + Uptime Kuma + a separate network diagram tool.

Versus Grafana + Prometheus. This is the comparison that matters for anyone serious about home lab monitoring. Grafana/Prometheus is the industrial standard — it handles arbitrary metrics, custom dashboards, alerting to Slack/PagerDuty, long-term retention, and scales to hundreds of hosts. It is also genuinely complex to configure and maintain. The Virtualization Howto review [1] acknowledges this directly: “You may already be using something like Netdata or Grafana and Prometheus. But these can be overkill for what you want or need to do.” CoreControl is the “good enough” answer for people who want visibility without an ops engineering project.

Versus Uptime Kuma. Uptime Kuma is the dominant self-hosted uptime monitoring tool — mature, feature-rich, with a massive community. CoreControl’s uptime monitoring is a subset of what Uptime Kuma does. The reason to pick CoreControl over Uptime Kuma is not that the monitoring is better; it’s that CoreControl bundles server inventory and network maps alongside it [4].

Versus Netdata. Netdata installs an agent per host and provides rich real-time metrics with cloud aggregation. CoreControl’s monitoring is lighter and simpler. For home labbers who don’t need per-process metrics and just want “is this thing up, how much RAM is it using” — CoreControl is faster to deploy and easier to read [1].

The GPU monitoring angle. The Virtualization Howto review [1] specifically calls out NVIDIA GPU monitoring as a concrete use case: if you’re running Ollama, llama.cpp, or Stable Diffusion locally, CoreControl can show GPU VRAM, utilization, and power draw during inference. For the growing slice of home labbers running local AI workloads, this is a genuinely useful signal that heavier monitoring stacks can require more configuration to surface cleanly.

What you won’t find in the third-party coverage: community complaints about bugs, data accuracy issues, or upgrade pain. That absence cuts both ways — either the tool works cleanly, or there isn’t enough user base yet to surface the failure modes. Given the star count (1,283), it’s probably both.

Features

Based on the README and the Virtualization Howto first-hand review:

Server management:

Add servers with hardware information (CPU, RAM, GPU specs)
Quick-links to management panels (iDRAC, Proxmox web UI, etc.)
System metrics: hostname, uptime, load averages [README][1]

Application tracking:

Register self-hosted applications with links
Uptime/downtime monitoring with history [README]
Searchable application list [README]
Notifications on state changes [README]

Infrastructure monitoring (via Go agent + Glances):

CPU usage per logical core in real time [1]
RAM usage: in-use vs available [1]
NVIDIA GPU stats: utilization, VRAM, power draw via nvidia-smi [1]
WebSocket-based UI for real-time updates [1]

Network:

Visual network flowcharts using React Flow [README]
The roadmap shows “Improved Network Flowchart with custom elements (like Network switches)” as a planned item, meaning current flowchart capability is basic [README]

What is explicitly WIP or roadmap:

The Dashboard section is marked “(WIP)” in the README — meaning the main overview screen is not finished [README]
“Advanced Settings (Disable Uptime Tracking & more)” is on the roadmap, not shipped [README]
Multi-user support, RBAC, and fine-grained access control are not mentioned anywhere in the documentation

Tech stack: Next.js + TypeScript frontend, Go agent, PostgreSQL via Prisma ORM, Tailwind CSS + shadcn/ui components, Lucide icons, React Flow for network diagrams, Glances for metric collection [README].

Pricing: SaaS vs self-hosted math

CoreControl has no SaaS tier, no cloud version, no commercial license, no enterprise edition. It is MIT-licensed software you run yourself. The cost model is simple:

CoreControl (self-hosted):

Software: $0 [README]
Infrastructure: whatever you’re already running Docker on

What you’re replacing (approximate costs):

Uptime Kuma: also free self-hosted — but you’re running it separately
Grafana Cloud free tier: free up to 10K metrics, then starts billing
Netdata Cloud free tier: free for 5 nodes, $5/node/month beyond that
PagerDuty or alerting SaaS: $21+/month for any serious notification routing

If you’re a home labber running everything on a single Proxmox host or a rack of mini PCs, the savings aren’t the story — you’re already self-hosting. The value calculation is time: how many separate tools are you maintaining, and would you rather maintain one?

For someone whose current stack is Grafana + Uptime Kuma + a hand-drawn Excalidraw network diagram, CoreControl reduces that to one application with three Docker containers. That has value even at $0 cost difference.

Deployment reality check

The deployment story is one of CoreControl’s genuine strengths. It is a Docker Compose file with three services — web, agent, PostgreSQL — and the compose file is published directly in the README [README]. You copy the file, set a JWT_SECRET environment variable, run docker compose up -d, and open http://localhost:3000 [1].

Default credentials: admin@example.com / admin — change these immediately [README].

What you actually need:

Any Linux host with Docker and docker-compose
About 512MB–1GB of RAM at idle (PostgreSQL + Next.js + Go agent combined)
Port 3000 available, or a reverse proxy (Caddy, nginx, Traefik) for HTTPS

What the Virtualization Howto review [1] confirms: the multi-service architecture (separate containers for web, agent, and database) is the current recommended path. An earlier version used FastAPI and Socket.IO; the project has evolved and the current Docker-based setup is the stable deployment method.

What can go sideways:

NVIDIA GPU monitoring requires nvidia-smi available on the host and the NVIDIA Container Toolkit installed — not bundled [1].
There is no built-in reverse proxy or TLS termination. If you want HTTPS (and you should), you set that up yourself.
The default PostgreSQL credentials in the sample compose file (postgres/postgres) are hardcoded examples — you need to change them before exposing this to any network beyond localhost [README].
No documented upgrade path from one version to the next. With 13 releases in roughly a year, the project is moving fast. Database migrations between versions may require manual steps — check the release notes before upgrading.
AlternativeTo lists 0 open issues as of the scrape, but the repository activity suggests this is more likely a reflection of issue tracking practices than an unusually stable codebase [4].

Realistic setup time for someone who has run Docker Compose before: 15–20 minutes to a working instance. For a non-technical user following the README: 1–2 hours including reverse proxy setup, HTTPS, and changing default credentials.

Pros and cons

Pros

Clean MIT license. No commercial tier, no usage restrictions, no “fair-code” ambiguity. Deploy it, fork it, embed it in your own tooling [README][4].
Single-file deployment. Three containers, one compose file. The Virtualization Howto review [1] confirms this works as documented.
Consolidates three tools. Server inventory + application uptime + network diagrams in one interface. For home labbers running multiple separate tools, this is a real reduction in maintenance surface [1].
NVIDIA GPU monitoring built in. Real-time GPU VRAM, utilization, and power draw via nvidia-smi — particularly useful for local AI inference workloads (Ollama, llama.cpp, Stable Diffusion) [1].
Modern tech stack. Next.js, Go, PostgreSQL, shadcn/ui — not an abandoned PHP panel from 2012. The codebase is approachable for anyone who wants to contribute or customize [README].
Fast to deploy. The gap between “docker compose up” and working dashboard is minutes, not hours [1][README].
13 releases in ~1 year. Active development with regular releases, not abandoned vaporware [GitHub].

Cons

Dashboard is marked WIP. The section you’d look at most often is explicitly unfinished [README]. You don’t know what’s missing until you need it.
1,283 stars. Small community means fewer eyes on bugs, fewer guides when something breaks, and real uncertainty about long-term project continuity. Compare to Uptime Kuma (65K+ stars) or Grafana [README].
No multi-user access control. There is one admin account. For a personal home lab this is fine; for a small team or shared infrastructure, it’s a hard limit [README][4].
No alerting integrations. “Notifications” are listed as a roadmap-completed item, but the documentation doesn’t specify integration with Slack, PagerDuty, email, or webhooks. What form those notifications take is unclear without hands-on testing [README].
Basic network flowcharts. The roadmap explicitly calls out “Improved Network Flowchart with custom elements” as a future item — meaning what ships now is limited [README].
No documented REST API. The merged profile lists rest_api as a canonical feature, but there is no API documentation in the README or linked docs. External integration is limited [merged profile].
Default credentials in compose file. postgres/postgres in the example config is a common mistake waiting to happen for less experienced self-hosters [README].
Zero third-party reviews outside Virtualization Howto. One review [1] and an AlternativeTo entry [4] is thin coverage for a tool you’d run on production infrastructure. There are no Reddit deep-dives, no Trustpilot ratings, no community forum threads to cross-reference.

Who should use this / who shouldn’t

Use CoreControl if:

You’re a home labber currently running Uptime Kuma + a separate dashboard + manual network diagrams and you want to reduce that to one thing.
Your monitoring needs are “is this service up, how much RAM is the server using” — not “give me 90 days of per-process memory trends.”
You’re running local GPU inference (Ollama, Stable Diffusion) and want a clean place to watch VRAM and GPU utilization.
You’re comfortable with Docker Compose and can set up a reverse proxy for HTTPS.
You value a clean, modern UI over raw feature depth.

Skip it (use Uptime Kuma instead) if:

You specifically need uptime monitoring with rich alerting (Slack, Telegram, email, webhooks) and a large community of guides. Uptime Kuma is more mature in every dimension of that use case.

Skip it (use Grafana + Prometheus instead) if:

You need historical metric retention beyond a few days, alerting on metric thresholds, per-process monitoring, or multi-tenant dashboards. CoreControl is not a metrics platform — it’s an infrastructure overview tool.

Skip it (use Portainer instead) if:

Your primary need is Docker container management — starting, stopping, inspecting containers and images. Portainer is purpose-built for that workflow; CoreControl is not.

Skip it entirely if:

You need the project to be stable and well-supported for production infrastructure. At 1,283 stars and an explicitly WIP dashboard, this is not yet the tool you bet a business on. It’s the tool you run in a home lab and watch grow.

Alternatives worth considering

From the AlternativeTo listing [4] and the self-hosted infrastructure category:

Uptime Kuma — the obvious alternative for the uptime monitoring piece. 65K+ GitHub stars, massive community, rich alerting integrations. Narrower scope (no server inventory or network maps) but far more mature.
Grafana + Prometheus — the power user stack. Arbitrary metric collection, sophisticated dashboards, alerting, long-term retention. Complex to set up and maintain, justified at scale.
Netdata — agent-per-host monitoring with a cloud aggregation layer. Richer real-time metrics than CoreControl with less configuration than Prometheus, but requires an agent on each host.
Glances — CoreControl actually uses Glances under the hood. If you want just the metrics layer without the application/server inventory wrapper, running Glances directly is simpler.
Portainer — container management focused. Better choice if your primary need is Docker/Kubernetes management rather than infrastructure overview.
Heimdall / Homer — self-hosted application dashboards (quick-link portals). More mature in the “here are all my services with links” use case, less so in the monitoring dimension.
1Panel — listed as a popular CoreControl alternative on AlternativeTo [4]. More full-featured server management panel with app store, more complex to operate.
Webmin — the veteran. Full Linux server management via web UI. More powerful, older codebase, steeper learning curve.
Coolify — self-hosted PaaS. Different category (deployment platform rather than monitoring dashboard) but shares the “manage self-hosted infrastructure via web UI” audience.

For a non-technical self-hoster who wants everything in one place and doesn’t need enterprise monitoring, the realistic shortlist is CoreControl vs Heimdall + Uptime Kuma separately. Pick CoreControl if you want consolidation with some active metric visibility. Keep Heimdall + Uptime Kuma if you want more mature tools and are comfortable running two things.

Bottom line

CoreControl is an honest attempt to solve a real home lab problem: you’re managing six self-hosted services across two servers, you have three separate monitoring tools, and you’re tired of maintaining all of them. It won’t replace a serious monitoring stack and it doesn’t try to. What it offers is a single Docker Compose file that gets you server inventory, application uptime tracking, network diagrams, and basic system metrics — GPU included — in under 20 minutes.

The caveats are real. At 1,283 stars it’s a young project, the dashboard is still marked WIP, there’s no multi-user access control, and one honest review versus dozens for its competitors means you’re making an early bet. If you’re looking for something to run on home lab hardware and iterate on as the project matures, CoreControl is worth the 20-minute deployment. If you need something proven and battle-tested for anything that matters, come back in a year.

If you want someone to deploy and configure your self-hosted infrastructure — CoreControl included — that’s exactly what upready.dev does for clients. One-time setup, you own the stack.