Rust Axum plus Cloudflare Tunnel — Operating policy-api.graxel.ai Safely

The policy API behind MyHyetaek needs predictable latency and a clear security boundary. Rust Axum is a good fit for this kind of service because request handling, typed state, and explicit errors stay readable as the API grows.

Why this matters for GRAXEL

A public-data API has to be stable even when the frontend changes. It also has to avoid exposing the database directly to the public internet. The operational challenge is balancing performance, safety, and low infrastructure cost.

GRAXEL places the Rust API behind a tunnel and keeps the application code focused on search, ranking, and response shaping. Cloudflare Tunnel removes the need to open broad inbound ports, while Axum keeps routing and typed extractors close to the domain logic.

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 pattern is useful for any service in the GRAXEL portfolio that needs more reliability than a quick serverless function but still has to stay inexpensive. 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

• Axum crate documentation
• Cloudflare Tunnel documentation

Production notes for an Axum service behind a tunnel

Running an Axum API through Cloudflare Tunnel is convenient, but I treat the tunnel as only one layer of the deployment. The service still needs its own health endpoint, structured logs, timeouts, and a clear restart path. When an incident happens, the first question is whether the Rust process is unhealthy, the tunnel is disconnected, the upstream dependency is slow, or Cloudflare is rejecting traffic. Without separate signals, every failure looks like the same 502.

My preferred setup is to keep the Axum application stateless where possible, expose a lightweight health route, and record request IDs across the tunnel boundary. I also avoid placing secrets in config files committed to the repository; environment variables and deployment-side secret stores are safer. For public APIs, I check CORS, rate limiting, and response sizes before exposing a new route. Rust gives excellent runtime stability, but it does not remove operational work. The combination works best when the tunnel is considered transport, not security by itself, and when rollback means switching traffic away quickly rather than debugging a live production process for too long.