The dashboard is a prototype before it is a FinOps system
Cloud Cost Optimization Hub has the recognizable pieces of a cost product: account registration, authentication, a dashboard, provider records, recommendations, PostgreSQL, Redis, and a Next.js frontend. The repository is small enough to follow, at 91 files and about 4,984 source lines. That makes it approachable for contributors. It also means buyers should inspect what each cloud adapter does instead of reading the multi-cloud label as equal support.
AWS has real Cost Explorer calls for daily and service-grouped unblended cost. Azure's service generates one fixed sample amount per day for the previous 30 days, and issue 5 says GCP generates mock records until someone connects Cloud Billing. The README calls mock cost data a v0.1 feature and describes real AWS, GCP, and Azure integration as readiness. The source is clearer: the three provider paths are not equivalent.
The 52-second backend install does not produce the advertised stack
Our sandbox entered backend/, installed 149 Go packages in 52 seconds, and built successfully in 58 seconds. The checkout used only 0.5 MB before dependencies. That is a low-cost way to inspect the API. The repository includes backend and frontend Dockerfiles plus a root Compose file, so the pieces look ready for container-based development at first glance.
The root README says make up starts the database, backend, and frontend. The current Makefile has build and test targets but no up target, and Compose defines only TimescaleDB and Redis. There is also no Helm directory even though the architecture list says a Helm chart handles production. To run the product, expect to start the Go API and Next.js app separately or write the missing orchestration yourself.
What happened when we ran it
Our 3-CPU, 8 GB Debian sandbox built the Go backend and ran its available tests. Go reported 1 passed and 0 failed in 21 seconds. The scan found 1 CI workflow, a Dockerfile, and no tests directory. A passing test is better than a compiler-only check, but one case cannot establish billing accuracy, authentication behavior, database migrations, or provider failure handling.
We did not run the frontend, PostgreSQL, Redis, or any cloud API, and the measurement block contains no browser or end-to-end result. The lab result therefore says the backend compiles at commit 8149d73 and its single parsed test passes. It does not validate the numbers shown on the dashboard. Cost software needs reconciliation against provider invoices before anyone uses it for budgets or savings decisions.
Azure and GCP do not yet report real bills
The Azure service validates a subscription ID, then creates sample compute records without calling Azure Cost Management. GCP's open issue 5 names the work still required: authenticate with a service-account key, call Cloud Billing, handle pagination, store records, and test against a real project where possible. A dashboard can look complete while both providers display synthetic data, so label demo accounts plainly if this is deployed internally.
AWS is further along, but issue 21 asks for unit tests around its most important service. The request covers successful responses, empty responses, and SDK errors. Our run's 1 test does not fill that gap. Before trusting AWS totals, test account permissions, time boundaries, pagination, currency handling, duplicate ingestion, and reconciliation. Those are ordinary billing concerns, yet the repository does not provide measured assurance for them today.
Daily ingestion is still an open task
Issue 14 says costs are fetched when a user adds an account and asks for a background job that refreshes every 24 hours. Without scheduled ingestion, the dashboard can become stale while still rendering normally. Open pull request 30 adds a last-synced display, which would make staleness visible, but it was not merged into the default branch when fetched. Visibility helps only after a reliable collector exists.
Redis is listed as the queue for background jobs, though the central daily workflow remains an issue. A production collector also needs retries, rate-limit handling, idempotency, per-account status, and alerts when credentials expire. None of those should be inferred from the presence of Redis. Treat the current queue service as infrastructure available for future work, not proof that ingestion runs unattended.
Credential handling needs a security pass
The sample environment asks for a database URL, JWT secret, and public API URL. Cloud accounts add stronger secrets: the AWS service reads an access key and secret from the stored account credentials, while the proposed GCP path expects a service-account JSON key. Issue 22 asks contributors to create a security disclosure file, so there is not yet a documented private reporting route for vulnerabilities.
A serious deployment should prefer read-only billing roles, encrypt provider credentials outside ordinary application rows, rotate keys, record access, and restrict registration. The README's development credentials expose TimescaleDB on port 5432 and Redis on 6379, which is convenient locally and unsuitable as an internet-facing default. These are solvable engineering tasks, but they belong ahead of importing production cloud credentials.
July activity does not make v0.1 production-ready
GitHub recorded the last push on July 13, 2026. The repository had 276 stars and 19 open issues and pull requests when fetched, with several UI pull requests updated on July 19. There was no latest GitHub release. Activity is recent enough to call the project maintained, while the open work remains concentrated on basic product functions such as ingestion, tests, health checks, security policy, and dashboard status.
Cloud Cost Optimization Hub is a useful teaching codebase and a plausible internal prototype. Its 149-package backend builds, and the small tree makes missing pieces visible. It is not yet the place to consolidate decisions across three real cloud bills. Adopt it only if finishing the collectors and operating model is the project you want; otherwise choose a tool whose supported cost source matches your estate.