Localhost. Online. Without opening your network.

From local service to a real external request

1. Install the approved signed Oxaa package and verify the release.
2. Run oxaa login and enroll the device.
3. Start and health-check the selected local service.
4. Run oxaa http <port> and wait for edge readiness.
5. Send a request from a provider sandbox, remote browser, phone or second network.
6. Confirm the request and response in the local application and Inspector.
7. Stop the route and remove callbacks, captures and test credentials when finished.

How traffic and Inspector data are handled

Oxaa's public edge terminates public HTTPS so it can resolve the exact hostname, identify the current authenticated route and forward the request. The session between the enrolled device and Oxaa is encrypted; the selected local service receives the request through that session.

Oxaa retains bounded account, route, usage, security, billing, support and diagnostic metadata required to operate and protect the service. Inspector body capture is a separate, explicit debugging action: the bounded request or response body copy shown by the local Inspector remains on the developer device and can be redacted, deleted or allowed to expire. Public traffic still has to be processed by the edge, so the accurate claim is local Inspector copies-not “Oxaa cannot see traffic.”

Choose the job you need

• Receive and verify webhooks in the real local handler.
• Complete OAuth and third-party callbacks through a real HTTPS URL.
• Share a branch or prototype without deploying it.
• Open a local app from a phone or another network.
• Test WebSocket and Server-Sent Events through a public edge.
• Bring routes, devices and ownership into one workspace when the workflow becomes shared.

More than a disposable URL

Oxaa manages public TLS, exact-host routing and the current authenticated route while preserving the HTTP behavior development workflows depend on. The same workflow connects to local inspection, network diagnostics and repeat-route controls. The protocols and limits page lists exact behavior and boundaries.

Route identity and the selected-service boundary

The enrolled device initiates the connection. Locally generated device identity, proof of possession, short-lived route generations and exact-host matching bind the hostname to the current route. Unknown, malformed, revoked or stale ownership fails closed instead of being forwarded to an uncertain destination.

Oxaa publishes only the configured local target. Private-network destinations require explicit authorization, while public, metadata, link-local, multicast and other unsafe destination classes remain blocked by policy.

Honest alternatives

A disposable utility may be enough for a low-risk one-off URL. An infrastructure connector fits private or production network access. A webhook gateway fits retries, fan-out and delivery operations. A cloud development environment fits a remotely hosted workspace. Oxaa is for a selected local endpoint, local inspection and a repeatable development workflow.

Choose by workflow, not by a vague allowance

Plan cards must show exact active endpoints, trusted devices, domains, transfer, capture, audit, concurrency, warnings, reset and cancellation behavior from one billing source of truth. Do not publish a vague “unlimited” promise.

Availability and commercial eligibility

Language preference, account country, billing country, service region, payment eligibility and support language are separate values. Show the current result before signup or checkout and never infer commercial availability from the page language alone.

What Oxaa is - and is not

Oxaa is development connectivity for a selected local HTTP or HTTPS service while the enrolled device and authenticated route are live. It is not application hosting, a general VPN, a forward proxy, permanent production deployment, raw TCP/UDP tunneling, arbitrary TLS passthrough, a CDN/WAF replacement or a production webhook delivery platform.

Frequently asked questions

Does Oxaa deploy my application?

No. The application continues to run on the enrolled device. Oxaa forwards requests to the selected local service only while the authenticated route is live.

Do I need to open an inbound port?

Normally no. The enrolled device initiates the session. A restrictive network can still block DNS, UDP/443, TCP/443 or intercept TLS, so diagnostics remain important.

Where do Inspector body copies live?

When bounded capture is explicitly enabled, the copy displayed by the local Inspector remains on the developer device. Oxaa still processes public traffic and retains bounded operational metadata.

Is this production hosting?

No. Use a deployed application, production ingress or event-delivery platform for production traffic.