Telescope finds the waste
A read-only scan of your fleet, classified by real CPU / memory / network / disk utilization — not sticker size.
Containarium · Cloud hosting
Without changing your infrastructure, your tooling, or the way your team already works.
What actually changes
Illustrative. Telescope measures your real utilization — the saving is sized from it →
Consolidate under-used VMs. No re-architecture, no code changes.
Full Linux boxes with systemd, real users, real sudo.
Apache 2.0. Self-host on LXC or your own Kubernetes.
Five minutes, zero risk
No credentials needed for the demo scan. For a real scan, a viewer-role service account is all Telescope ever gets.
# build from source (Go, Apache 2.0)
$ git clone https://github.com/FootprintAI/telescope && cd telescope
$ go build -o telescope ./cmd/telescope
# no cloud creds? see what a report looks like on synthetic data
$ ./telescope scan --provider mock
# real scan — GCP, with the read-only service account you created
$ ./telescope scan --provider gcp --projects my-project \
--credentials ./readonly-sa.json --lookback 14d \
--output csv --out report.csv
# or AWS
$ ./telescope scan --provider aws --regions us-east-1 \
--lookback 14d --output csv --out report.csv
GCP scans need only roles/compute.viewer,
roles/container.viewer, and
roles/monitoring.viewer — no write permissions, ever.
After the scan
Containarium doesn't replace your cloud provider — it runs on it. Right-sized boxes on the GCE / EC2 capacity you already pay for, driven by the workflow you already have.
A read-only scan of your fleet, classified by real CPU / memory / network / disk utilization — not sticker size.
Under-used VMs collapse into fewer, right-sized Containarium boxes on the same cloud account — real Linux, real sudo, real systemd.
ssh, terraform, systemd, your existing CI — all still point at the same provider. Apache 2.0, self-hostable, no lock-in.
Real result
A client came to us running six VMs — 16 cores, 64 GB RAM, and 1 TB disk each, every one sized for peak. After the switch to Containarium, same workloads, 20% off the bill.
We moved six peak-sized VMs onto Containarium and cut the bill by 20% — without giving up performance. Our ops team still maintains and upgrades everything the same way it always has.
Your number depends on your utilization — that's what the Telescope scan measures.
FAQ
Telescope is a free, open-source (Apache 2.0) scanner. You point it at a read-only service account on your GCE or AWS account, and it classifies every instance by real utilization — CPU-bound, memory-bound, network-bound, disk-bound, or idle. It never writes to your infrastructure.
No. Telescope only reads metrics through a viewer-role service account you create and control — on GCP that's just roles/compute.viewer, roles/container.viewer, and roles/monitoring.viewer; on AWS a read-only policy over EC2, EKS, and CloudWatch. It doesn't touch your VMs, your CI, or your deploy pipeline. Consolidation only happens later, and only if you choose to act on the report.
From your own utilization data, not a generic estimate. Telescope measures how much of each instance's CPU, memory, network, and disk you actually use, then we size a consolidation plan onto fewer, right-sized Containarium boxes from that measured data — savings of up to 20%, illustrative and workload-dependent.
No. Containarium boxes run on your own cloud provider account, driven by the same ssh / terraform / systemd / CI workflow you already use. No re-architecture, no code changes. You can also self-host Containarium yourself under Apache 2.0 — no lock-in.
Run the free Telescope scan, send us the report, get your consolidation plan back.