Multi-Cloud Free-Tier Platform
One dashboard provisions free-tier compute across four clouds with Terraform, and an hourly sweep keeps every account tidy.
- 01Request path
- 02The browser never picks the machine
- 03Four independent locks
- 04Tenant isolation
- 05Worker & hourly sweeper
- 06Credentials & encryption
Architecture Overview
One dashboard that provisions real compute on AWS, GCP, Azure or Oracle Cloud with Terraform, strictly inside each provider's free tier, then lists it all in one place and tears it down automatically after 24 hours. It owns no hardware: you supply your own cloud credentials and it acts on your behalf, more valet than rental company. Provisioning is the straightforward part — the interesting work is making a surprise bill structurally impossible.
How it works
Core mechanics, failure recovery paths, and system design decisions.
Request path
A clean Flask app factory saves credentials and state-change requests to PostgreSQL with a connection pool. Building an instance takes one to three minutes, so the API inserts a pending row and answers in 50ms while the frontend refreshes via 5-second HTML partial polling.
The browser never picks the machine
A request carries only a provider and a resource type. Instance size, region and image are looked up server-side and written into Terraform, so there is no field in which to ask for a $5,000 GPU box, however the request is forged.
Four independent locks
The allowlist, the server-side locked spec, Terraform variable validation inside the module itself, and a cap of one resource per provider with a 24-hour timer. All four have to be picked, not one.
Tenant isolation
Each user and provider gets its own Terraform workspace, with the module files symlinked rather than copied — one blueprint, many private state files — and every database query scoped by user, so another tenant's resource simply 404s.
Worker & hourly sweeper
Lean shell daemons replace heavy message brokers: worker.sh claims pending jobs and drives Ansible playbooks (provision.yml / destroy.yml), while sweeper.sh runs an hourly loop to flag expired resources for automated teardown.
Credentials & encryption
Cloud keys are Fernet-encrypted before reaching PostgreSQL and decrypted in memory only by the worker playbooks at provision or destroy time. User passwords use bcrypt; session state is managed via secure session cookies.
Engineering Highlights
- •Free-tier enforcement in four layers, two of them below the API
- •Lean orchestration: worker.sh and sweeper.sh replace Celery with Ansible playbooks
- •Every resource is destroyed within 25 hours, forgotten or not
- •Per-tenant Terraform state, with shared modules by symlink
- •Cloud credentials encrypted at rest with Fernet and never exposed
- •Honest about its edges: Azure and Oracle modules are stubs, and state locking is local