Data for Good Calgary — Cloud Infrastructure
Data for Good Calgary
Challenge
Data for Good Calgary's entire data platform — a 26ai Autonomous Database holding 17 schemas and six live APEX applications — sat in a personal OCI tenancy that Oracle had scheduled for reclamation. The chapter had a hard deadline, no budget for downtime, and no infrastructure team. Alongside it, the self-hosted platform stack running NextCloud, Mautic, DocuSeal and Collabora had no monitoring at all: the first sign of an outage was a volunteer reporting it.
Solution
Migrated the Autonomous Database across OCI tenancies into the organization's CIS landing zone using a native cross-tenancy clone, then rebuilt the surrounding production topology — private endpoint, flexible load balancer, Let's Encrypt certificates with automated renewal, and reconnected applications. Deployed three-layer observability across the compute host so failures surface before users notice rather than after a volunteer reports them.
Results
- ✓ 17 schemas and 6 APEX apps migrated before the reclamation deadline
- ✓ Moved into a governed CIS landing-zone tenancy
- ✓ Automated TLS renewal replacing manual certificate work
- ✓ Container, host and synthetic monitoring deployed
The deadline was not negotiable. Oracle had scheduled the personal tenancy holding Data for Good Calgary’s database for reclamation, and everything the chapter ran — 17 schemas, roughly 384 MB, six active APEX applications — was inside it.
Cross-tenancy migration
The target was DATAFORGOOD, the organization’s CIS landing-zone tenancy in ca-toronto-1 — a governed environment with proper compartments and policies, rather than another personal account. Moving between tenancies is not a supported click in the console; it needs deliberate setup:
- IAM endorsement and admission policies on both sides, so the destination tenancy is permitted to read the source database and the source is permitted to allow it
- A free-tier upgrade on the source — cross-tenancy cloning is not available to always-free instances, so the source had to be converted to paid for the duration of the move
- Region parity — both tenancies in the same region, which they were
With the policies in place, OCI’s native full clone did the data movement. The migration completed on schedule.
Making the new database production-ready
A cloned database is not a running service. The rebuild around it:
- Private endpoint — the database is not reachable from the internet
- Flexible load balancer in front of it, terminating TLS
- Let’s Encrypt certificates issued and renewed automatically by a cert manager on a co-located compute instance, so nobody has to remember a 90-day renewal
- Application reconnection — all six APEX applications repointed and validated against the new endpoint
Observability
The platform stack — NextCloud, Mautic, DocuSeal, Collabora — runs as containers on a single OCI compute VM. Three complementary agents report into a self-hosted OneUptime instance:
| Layer | Agent | Covers |
|---|---|---|
| Containers | OneUptime Docker agent | Per-container metrics and logs |
| Host | OpenTelemetry Collector | CPU, memory, disk, filesystem, load, network, per-process |
| Service | Infrastructure agent + synthetic monitors | Heartbeat, HTTP checks, SSL expiry |
Synthetic and certificate monitors close the loop: an expiring certificate or a failed public endpoint raises an alert rather than a volunteer email.
The set
This completes a three-part engagement for the chapter — the volunteer platform that runs the projects, the marketing automation migration that handles outreach, and the infrastructure here that everything sits on.