Solutions
You have an edge problem. We solve it.
Three problems come up again and again: migrating off nginx without a rewrite, putting one policy point in front of every service, and standing up an MCP gateway your team can actually audit. We work each one to a production outcome.
Edge & traffic
Your edge, migrated without a rewrite.
You're running nginx in production and it works — but you want faster TLS, a memory-safe core, or a Kubernetes ingress that doesn't fight your existing config. Rewriting every route to adopt something new isn't a project you can staff.
- We run xin beside your current server on a spare port, evaluate it against your real config and traffic, and hand you a cutover plan you control.
- Same configuration language, same operational commands, same TLS termination in front of the same upstreams.
- Kubernetes ingress via xingress (OCI/Helm) using the Ingress resources you already have, or the Gateway API controller where you're standardising on it.
- A native /metrics endpoint your existing Prometheus setup scrapes on day one, no new exporter to deploy.
- Analytics without a parsing tier: JSON access logs flow straight into ClickHouse or any OpenTelemetry backend — no log-parsing sidecar.
Authentication at the gateway
One policy point in front of every service.
Every service behind your edge rolls its own auth check, and every team maintains its own copy of the same logic. You want one place to enforce identity, access rules and rate limits — not twelve.
- auth_request against the identity provider you already run, so the gateway makes one call per request and your services trust the result.
- auth_basic and per-route access control for the services that need a simpler gate.
- Rate limits enforced at the same layer, per route or per client, so a runaway caller can't reach your backends at all.
MCP & AI tooling
Your AI tools get an edge with policy, not a side door.
Your team is standing up MCP tool servers, and each one needs routing, access control and an audit trail. Building a separate gateway for tool traffic means a second set of infrastructure to run and secure.
- mcp_pass routes to stdio tool servers you spawn or HTTP tool servers you already run, on the proxy you already operate.
- Tool-level allow/deny with mcp_allow_tool and mcp_deny_tool, and per-tool rate limits — the same limit_req you use everywhere else.
- One audit trail: $mcp_tool and $mcp_method land in the same log_format as the rest of your traffic.
Talk to us
Tell us what you're running.
Describe your current setup and the problem you're solving, and we'll respond with a concrete plan — not a sales deck. Commercial licensing and support come direct from the engineers who wrote xin, not a separate support tier.