Using Oracle Cloud Always Free ARM for Production APIs

Some workloads do not fit well into a purely frontend deployment. Policy search, batch jobs, vector indexes, and long-running services often need a real server with predictable memory.

Why this matters for GRAXEL

The challenge is not only creating the server. It is keeping the boundary clear: the portal should remain easy to deploy, while the heavier API server handles the data-intensive work behind a controlled interface.

GRAXEL uses the ARM server for backend services that benefit from memory and process control. The public site can still deploy through Cloudflare, while specialized APIs run where the workload makes sense.

Operational notes

• Keep the user-facing promise narrow enough that the service can be verified in a browser.
• Document the boundary between automated AI output and source-backed data so reviewers can understand the workflow.
• Link the implementation back to the public trust pages: About GRAXEL, Contact, and the platform overview.

For a small SaaS portfolio, trust comes from showing the real operating system behind the product: what runs, why it exists, and how it is maintained.

What changed in practice

This split keeps the brand surface fast while allowing serious backend systems such as policy search and automation to evolve independently. The same pattern now influences how the portal presents public services: planned ideas stay out of the main catalog, while usable beta services and documented operating notes receive stronger internal links.

When this article is read together with the monorepo operations note and the zero-cost infrastructure note, it gives a more complete view of how GRAXEL turns small service ideas into maintained products.

Official references

• Oracle Cloud Always Free resources
• Cloudflare Tunnel documentation

Operating within Always Free limits

Oracle Cloud ARM instances can be a useful home for small production APIs, but the safe approach is to design as if capacity is limited from the beginning. I avoid assuming that more CPU, disk, or network headroom will always be available. A lightweight API should have bounded logs, clear memory limits, and a backup plan for configuration and database state. The most common failure is not dramatic downtime; it is a slow accumulation of logs, cache files, or build artifacts until the instance becomes difficult to maintain.

Before I place a service there, I document the boot process, firewall rules, deployment command, environment variables, and rollback command. I also prefer health checks that verify the actual dependency path, not only that the process is alive. If a database or external API is required, the health view should make that visible. For cost control, I avoid attaching experimental workloads to the same instance that serves production traffic. Free infrastructure is only free when it does not consume hours of emergency recovery. The right question is not whether the machine can run the service today, but whether I can rebuild it calmly tomorrow.

Extra review step

I keep a tiny rebuild note for each API host: base image, packages, service file, environment names, domain mapping, and restore command. The note is intentionally short enough to follow during an outage. If rebuilding the instance requires searching chat history or guessing firewall settings, the system is not production-ready even if it runs correctly today.