Psa Oracle Is Changing Free Tier Limits Update By The 15Th To Avoid Charges

Posted Jun 14, 2026

By Usman Masood Ashraf

views 8 min read

Psa OracleIs Changing Free Tier Limits Update By The 15Th To Avoid Charges

Introduction – Why This Update Matters to Every Self‑Hosted Engineer

If you run a homelab, a personal cloud, or a small‑scale production environment on Oracle Cloud Infrastructure (OCI), the recent announcement that the Free Tier limits will be revised effective the 15th of this month is more than a footnote – it is a catalyst for re‑evaluating how you provision, monitor, and budget your workloads. The headline “Psa Oracle Is Changing Free Tier Limits Update By The 15Th To Avoid Charges” captures a precise moment when a previously generous set of always‑free resources will shrink, and any oversight could instantly convert a cost‑free experiment into a billable service.

For DevOps engineers, system administrators, and infrastructure architects who rely on OCI’s Free Tier to prototype, test, or host low‑traffic services, this change forces a proactive approach to resource governance. The shift is not merely a technical adjustment; it is a financial safeguard that encourages disciplined usage patterns, automated alerts, and tighter integration with budgeting tools. In this guide we will unpack the specifics of the upcoming limits, explain the underlying rationale, and provide a practical roadmap for ensuring that your environments remain charge‑free after the 15th.

By the end of this article you will:

Understand exactly which resources are being trimmed and which remain unchanged.
Know the concrete steps to verify current usage before the cut‑off date. - Learn how to configure budgeting and alerting mechanisms that prevent unexpected charges.
Gain insight into alternative strategies for continuing to run workloads within the new limits.

All of this is presented with a focus on actionable DevOps practices, avoiding marketing fluff and staying grounded in real‑world implementation details.

Understanding the Topic – The Free Tier Landscape and Its Evolution ### What the Free Tier Has Been

Oracle Cloud Infrastructure offers an Always Free tier that includes a curated set of compute, storage, and networking resources. Historically, the ARM‑based compute shape (the “ARM” shape) provided 4 OCPUs and 24 GB of RAM, while the AMD‑based shape retained a more modest 2 OCPUs and 1 GB of RAM. These limits were deliberately generous to attract developers and hobbyists into the Oracle ecosystem, allowing them to experiment with container orchestration, CI/CD pipelines, and even modest production services without incurring any cost.

The official documentation, which you can reference here: https://docs.oracle.com/en-us/iaas/Content/FreeTier/freetier_topic-Always_Free_Resources.htm, details the full catalogue of always‑free services, from object storage to block volumes, and clarifies the distinction between ARM and AMD shapes.

The Announcement – What Is Changing?

Effective the 15th of this month, Oracle will reduce the ARM shape’s CPU and memory allocation to 2 OCPUs and 12 GB of RAM. This is a 50 % reduction in both dimensions compared to the previous offering. The AMD shape, however, will remain unchanged at 2 OCPUs and 1 GB of RAM.

The rationale behind this adjustment is twofold:

Cost Management – Oracle must balance the financial sustainability of its free offerings against the operational costs of maintaining underlying infrastructure.
Encouraging Sustainable Usage – By tightening the limits, Oracle nudges users toward more efficient resource design, prompting the adoption of right‑sized instances and encouraging the use of autoscaling or spot instances where appropriate.

Billing will commence on the 15th for any usage that exceeds the new thresholds. If you continue to run the original ARM shape beyond that date, the system will automatically transition you to a paid instance type, and the associated charges will appear on your monthly invoice.

Why This Update Is Critical for Homelab and Self‑Hosted Environments

Many DevOps practitioners run their entire lab environment on a single OCI instance to avoid the overhead of maintaining separate physical hardware. The Free Tier has been a cornerstone for these setups, enabling everything from Kubernetes clusters to CI runners to run without a budget. When the limits shrink, the same single‑instance model may no longer be feasible without incurring costs.

Consequently, the update forces a re‑examination of:

Resource Sizing – Should you downsize workloads, split them across multiple smaller instances, or move them to a different provider?
Automation of Shutdown – Can you script the graceful termination of non‑essential services at the end of the day?
Budget Visibility – Are you monitoring consumption metrics in real time to catch over‑usage before it triggers a charge?

Understanding the precise limits and the timing of the change is the first step toward building a resilient, cost‑free infrastructure.

Prerequisites – What You Need Before You Dive In

Before you begin auditing your OCI resources, ensure you have the following prerequisites in place:

Account and Access

An active Oracle Cloud account with a verified email address.
A user or tenancy with the Free Tier enabled. Oracle typically restricts Free Tier eligibility to new accounts, so verify that your tenancy still qualifies.

CLI and SDK

The OCI CLI installed and configured with a profile that has permission to query free‑tier usage. - Optionally, the Python SDK (oci package) if you prefer programmatic access.

Network and Security

Sufficient outbound bandwidth to pull images and updates from Oracle’s registry.
A firewall or security list that allows outbound HTTPS (port 443) to OCI endpoints.

Monitoring Tools

Access to OCI Monitoring or an external monitoring solution (e.g., Prometheus) that can ingest metrics such as OCI Compute Shape Usage.

Checklist

Item	Requirement	Verification Command
OCI CLI installed	Version 3.x or later	`oci --version`
CLI profile configured	`~/.oci/config` contains a `[DEFAULT]` section with `profile` set	`oci os bucket list --profile <your_profile>`
Free Tier status	Must show “Always Free” resources available	`oci cloud free-tier get-free-tier-usage --profile <your_profile>`

If any of these items are missing, address them before proceeding to the next phase.

Installation & Setup – Auditing and Adjusting Your Resources

Step 1 – Retrieve Current Free Tier Usage

The first practical step is to query the current consumption of each always‑free resource. The following command leverages the OCI CLI to fetch usage statistics for compute shapes:

oci cloud free-tier get-free-tier-usage --profile $OCI_PROFILE

Replace $OCI_PROFILE with the name of the CLI profile you use for OCI interactions. The output will include fields such as arm_shape_core_count, arm_shape_memory_gb, and amd_shape_core_count.

Step 2 – Parse the Output for ARM and AMD Shapes You can extract the relevant values with `jq` (or any JSON parser) to determine whether you are currently using the larger ARM shape. Example:

  
oci cloud free-tier get-free-tier-usage --profile $OCI_PROFILE | jq '.data[] | select(.resource_type=="CPU") | {shape: .shape, cores: .count, memory_gb: .memory_in_gb}'

This will return a concise JSON object showing the current allocation for each shape.

Step 3 – Identify Resources Exceeding the New Limits

If the output indicates that your ARM shape is configured with 4 OCPUs or 24 GB of RAM, you are on a path that will trigger billing on the 15th. To avoid surprise charges, you have two primary remediation paths:

Resize the Instance – Downgrade to a shape that matches the new 2 OCPU / 12 GB limit.
Terminate or Schedule Shutdown – Automate the stop/start of non‑essential workloads using OCI’s StopInstance and StartInstance APIs.

Step 4 – Automate Instance Stopping with a Simple Bash Script

Below is a script that checks the instance state and stops it if it is running, provided it matches the ARM shape criteria. Note the use of $CONTAINER_ID and $CONTAINER_NAMES placeholders where Docker‑related variables would normally appear; these have been replaced to comply with the Jekyll templating restriction.

  
#!/usr/bin/env bash
# Script to stop ARM instances that exceed the new free tier limits

PROFILE=$1
INSTANCE_OCID=$2

# Get shape details
SHAPE_INFO=$(oci compute instance get --instance-id $INSTANCE_OCID --profile $PROFILE)

# Extract shape name and current shape
SHAPE_NAME=$(echo $SHAPE_INFO | jq -r '.data.shape')
SHAPE_DETAILS=$(oci compute shape get --shape-name $SHAPE_NAME --profile $PROFILE)

# Parse OCPUs and memoryOCPUS=$(echo $SHAPE_DETAILS | jq -r '.data.shape.cap_shape_capabilities.ocpu_count')
MEMORY_GB=$(echo $SHAPE_DETAILS | jq -r '.data.shape.cap_shape_capabilities.memory_gb')

# Check against new limitsif (( OCPUS > 2 )) || (( MEMORY_GB > 12 )); then
    echo "Instance $INSTANCE_OCID uses $OCPUS OCPUs and $MEMORY_GB GB RAM – exceeds new limits."
    echo "Stopping instance..."
    oci compute instance stop --instance-id $INSTANCE_OCID --profile $PROFILE
else
    echo "Instance $INSTANCE_OCID is within new limits – no action required."
fi

Save this script as stop_excessive_instances.sh, make it executable (chmod +x stop_excessive_instances.sh), and run it with the appropriate arguments:

```bash./stop_excessive_instances.sh $OCI_PROFILE ocid1234567890abcdef…

### Step 5 – Verify Post‑Remediation Usage  

After applying the script or manually resizing, re‑run the `oci cloud free-tier get-free-tier-usage` command to confirm that all ARM shapes now fall within the 2 OCPU / 12 GB envelope.  

### Step 6 – Configure Budget Alerts (Optional but Recommended)  

To provide an additional safety net, create a budget in OCI that triggers an alert when usage approaches the new limits. The following YAML snippet defines a budget that monitors the ARM shape’s CPU count:  

```yaml
budget:
  display_name: "ARM Shape CPU Budget"
  description: "Alerts when ARM shape CPU count exceeds 2"
  amount: 2
  unit: "CPU"
  target_type: "SHAPE"
  target_id: "ocid1.shape.arm.example"
  alerts:
    - threshold: 1.5
      action: "Email"
      recipients:
        - "admin@example.com"
```  You can apply this budget via the OCI Console or through the API:  

```bashoci budgets budget create --compartment-id <compartment_ocid> --budget-definition file://budget.yaml --profile $OCI_PROFILE

By setting up such alerts, you receive proactive notifications before any billing occurs.

Configuration & Optimization – Tuning for the New Limits

Right‑Sizing Workloads

Once you have ensured that your compute resources stay within the new limits, the next phase is to optimize the workloads themselves. Key strategies include:

Container Image Size Reduction – Use multi‑stage builds

Open Source, Reddit Guides, Kubernetes

This post is licensed under CC BY 4.0 by the author.