- Data never leaves your chosen edge: Ingest and query both run at your edge deployment. Your raw event data never leaves to be processed elsewhere.
- One product, everywhere: Every user logs in at app.axiom.co. No more separate EU subdomain, the full Axiom experience regardless of where your data lives.
- Unified billing: Credits and discounts apply across all your edge deployments. You get one bill, and usage rolls up globally.
- Datasets across multiple edge deployments: Each dataset lives in a single edge deployment, but your organization can span as many as you need. Everything surfaces in one console.
- New edge deployments can come online faster: Standing up a new deployment no longer means cloning an entire platform. US East and EU Central are live now.
For EU customers who needed their event data resident in Europe, using Axiom meant a quiet tradeoff. To store data in Europe, you logged into a different product: app.eu.axiom.co, a parallel deployment with its own API endpoints, its own release cycle. Features sometimes arrived late. Billing was separate. There was a regular investment in effort from the Axiom engineering team to ensure that the two deployments couldn't drift in subtle ways.
The problem wasn't unique to EU. It was fundamental to how Axiom was built. Every new geography meant duplicating the entire platform: auth, billing, orgs, datasets, monitors, the full stack.
Today we're shipping the architecture that can deliver on data residency requirements without making these compromises. Axiom now runs on edge deployments, coordinated by a global control plane. Your data, wherever it lives, never leaves. The rest of the product: your account, your billing, your team, works from one place.
How it's built
Our new architecture separates the global from the local along a clean boundary.
The global control plane handles authentication, authorization, org and user management, billing, and routing. It knows where every dataset lives and which edge deployment serves it. Crucially, it's a single global instance. There's one source of truth for your account.
Edge deployments are the local data plane. Each one runs the components that actually touch your data: our query engine, our data store, and our ingest pipeline. When you ingest data, it lands at your edge deployment. When you query, the query runs there too. Results come back from the edge directly.
The two layers communicate through a minimal internal API. When the global control plane needs to tell an edge about a new ingest token, or propagate a dataset deletion, or enforce a plan limit, it sends a message to the relevant edge. Edge deployments call back for the information they need: token validation, dataset mappings, rate limit configs. That's the full surface area.
What this looks like in practice
When you configure your SDK or collector for ingest, you simply specify the edge deployment you want to use through the ingest URL.
Querying in console looks and feels just as it did before. Depending on the dataset queried, Axiom routes the query to the appropriate edge, and the query executes there. The response comes back to your browser, without the results being routed anywhere else first.
Your org, your API tokens, your team members: all of that lives in the global control plane. Logging into app.axiom.co from anywhere gives you the full picture.
When you need to demonstrate that your observability data doesn't leave the EU, the answer is straightforward: it ingests at eu-central-1.aws.edge.axiom.co, it stores there, and queries execute there.
Datasets across multiple edge deployments
With Axiom's new architecture, you can store datasets in different edge deployments within the same organization. A dataset in US East and a dataset in EU Central both appear in the same console, under the same account. Monitors, dashboards, and queries work across both. There's no concept of "switching to a different deployment" as a user: you just see your data.
Credits and volume discounts are shared, regardless of how many edge deployments you're using. You see one bill.
You can still see breakdowns per deployment on your usage page if you want the detail, but the defaults are unified. Using multiple edge deployments shouldn't feel like a separate procurement exercise.
Adding edge deployments from here
One of the cleaner results of this architecture is what it costs to expand. Previously, standing up coverage in a new geography meant deploying another copy of the full platform. The new answer is to stand up an edge deployment: event storage, metrics, streaming, and a small internal API that speaks to the global control plane.
We're starting with US East and EU Central. If you need data residency in a geography we don't yet serve, reach out and let us know.
Get started
- Read the docs: Edge deployments reference has the full technical picture, including how to configure your SDK and ingest endpoints.
- Choose your edge deployment: When creating a new organization, you choose your default edge deployment at sign-up. US East and EU Central are both available.
- Contact us about EU migration: If you're on the legacy EU deployment and want to understand the migration timeline, get in touch.
