Quartz 4

08 - Oracle Cloud Free Tier & Infrastructure Optimization

5 min read

Oracle Cloud Free Tier & Infrastructure Optimization

Overview

Oracle Cloud Infrastructure (OCI) offers the most generous Always Free tier in cloud computing. This document breaks down our hardware constraints, host memory optimizations, and the background capacity hunting automation working 24/7 to secure a high-performance Ampere A1 ARM compute instance (2 OCPUs, 12 GB RAM).

1. Oracle Cloud Free Tier Quotas & Financial Safety

flowchart LR
    subgraph ActiveHost ["Active 24/7 Micro Host"]
        AMD["AMD Micro VM (1 OCPU, 1 GB RAM)"]
        Swap["2.0 GB Swapfile (/swapfile)"]
        Storage1["50 GB Boot Volume"]
    end

    subgraph TargetARM ["Pending Capacity Hunt"]
        A1["Ampere A1 ARM (2 OCPUs, 12 GB RAM)"]
        Storage2["50 GB Boot Volume"]
    end

    subgraph TenancyPool ["Always Free Allowance Pool"]
        Cores["Ampere Cores: 2 OCPUs / 12 GB RAM"]
        MicroPool["AMD Micro: 2 VMs"]
        DiskPool["Block Storage: 200 GB Total"]
    end

    ActiveHost -.-> TenancyPool
    TargetARM -.-> TenancyPool

Why Stay on “Pure Free Tier”?

While Oracle allows upgrading tenancies to “Pay As You Go” (PAYG) for higher provisioning priority:

  1. The change is irreversible. Oracle offers no mechanism to revert an account back to Free Tier.
  2. Financial Risk: Accidental resource creation, storage overshoot (>200 GB), or egress bursts result in immediate credit card charges.
  3. Pure Free Tier Protection: A pure free tier account physically cannot incur charges. Any request for paid resources is rejected outright by Oracle’s billing gatekeeper.

Recent Free Tier Quota Adjustment

Older guides on the internet state that Always Free accounts receive 4 OCPUs and 24 GB RAM. Oracle has officially adjusted the Always Free Ampere A1 quota to 2 OCPUs and 12 GB RAM. Attempting to request 4 OCPUs on a pure Free Tier tenancy will fail.

2. Current Host: AMD Micro VM Memory Tuning

Our active 24/7 host (144.21.49.153) is an VM.Standard.E2.1.Micro instance with 1 GB of physical RAM. Running Caddy, Authelia, Vaultwarden, Homepage, and Wealthfolio simultaneously requires strict memory tuning:

A. The 2 GB Swapfile

To prevent Linux Out-Of-Memory (OOM) killer events from terminating Docker containers:

  • Configured at /swapfile (2,048 MB).
  • Virtual memory parameters in /etc/sysctl.conf:
    • vm.swappiness = 60 (balances RAM caching and swap utilization).
    • vm.vfs_cache_pressure = 50 (encourages the kernel to retain directory and inode cache).

B. Container Hard Memory Caps

In /opt/vaultwarden/docker-compose.yml, memory reservations and limits are assigned to ensure no single container can starve the host:

  • wealthfolio: Hard limit 256M, reservation 64M.
  • homepage: Typical footprint ~70M.
  • vaultwarden: Typical footprint ~35M.
  • authelia: Typical footprint ~45M.
  • caddy: Typical footprint ~25M.

3. Ampere A1 Auto-Provisioning System

Because free ARM instances in London (uk-london-1) are perpetually in high demand, manual creation attempts in the web console almost always fail with:

Out of host capacity

The Solution: Automated API Capacity Polling

A Python script runs directly on the active AMD Micro instance via cron every 5 minutes. The moment another cloud user terminates an ARM instance, our script detects the released capacity and claims it immediately via the official OCI Python SDK.

flowchart TD
    Cron["Cron (Every 5 min: /home/ubuntu/launch_arm.py)"] --> FlagCheck{"Does instance_created.flag exist?"}
    FlagCheck -- Yes --> Halt["Stop (VM Already Provisioned)"]
    FlagCheck -- No --> Auth["Authenticate via OCI API SDK (RSA PEM)"]
    
    Auth --> TryAD1["Attempt Launch in UK-LONDON-1-AD-1"]
    TryAD1 -- "Out of host capacity" --> TryAD2["Attempt Launch in UK-LONDON-1-AD-2"]
    TryAD1 -- "Success" --> Alert["Fire Dual Alerts (Email + Ntfy)"]
    TryAD2 -- "Out of host capacity" --> Sleep["Log notice & Sleep until next cron"]
    TryAD2 -- "Success" --> Alert
    
    Alert --> WriteFlag["Save instance_created.flag"]

Key Technical Findings in London (uk-london-1):

  • London has 3 Availability Domains (AD-1, AD-2, AD-3).
  • Ampere A1 (VM.Standard.A1.Flex) hardware only exists in AD-1 and AD-2.
  • AD-3 returns 404 Not Found for A1 shapes. The script specifically filters for AD-1 and AD-2 to avoid wasted API calls.

Dual Alert Notification Channels

The instant the ARM instance is successfully claimed:

  1. Oracle Cloud Email (gs9339@gmail.com): Published directly to the OCI Notification Topic Altert.
  2. Instant Push Alert via Ntfy: Broadcasts to https://ntfy.sh/oracle-alert-gs9339-arm (can be subscribed to via the free Ntfy app or browser).

4. Migration Plan: Moving to the 12 GB ARM Powerhouse

Once the Ampere A1 VM is provisioned:

flowchart LR
    Step1["1. Connect to new ARM VM"] --> Step2["2. Run 15-Min Disaster Recovery (Doc 07)"]
    Step2 --> Step3["3. Re-point Cloudflare Tunnel Token"]
    Step3 --> Done["All services running with 12 GB RAM!"]
  1. Zero Data Loss: We run the recovery runbook from 07 - Automated Backup & Disaster Recovery on the new instance.
  2. Instant Cutover: Move the Cloudflare Tunnel token (/etc/cloudflared/token) to the new ARM VM and start the service.
  3. Seamless Transition: Cloudflare routes all traffic to the new ARM instance instantly with zero DNS propagation wait times.

5. Daily Operations Cheatsheet

Check Host Memory & Swap Utilization

ssh -i ~/.ssh/oracle_vm.key ubuntu@144.21.49.153 "free -h"

Check ARM Hunting Script Status

ssh -i ~/.ssh/oracle_vm.key ubuntu@144.21.49.153 "tail -n 20 /home/ubuntu/launch_arm.log"

Verify if the ARM VM Has Been Claimed

ssh -i ~/.ssh/oracle_vm.key ubuntu@144.21.49.153 "ls -la /home/ubuntu/instance_created.flag 2>/dev/null || echo 'Still hunting capacity...'"

6. Next Steps & Related Links

Graph View

Backlinks