At the end of Q2, we talked about how quickly AI is changing software development. Three months later, that shift is only accelerating.

It has never been easier to build software. AI can generate an application, write an API, and connect a database in minutes. Building is quickly becoming a commodity. Soon there will be more code than anyone can review line by line.

But building the first version is only the beginning.

The harder questions come as the software starts to matter and more people work on it. How do you understand what AI built? How do several people and agents work on it under the same rules? And how do you move it into production, next to the systems you already run?

Most platforms answer with parts. A database here, a runtime there, and the assembly is left to you.

Xano takes the other path. It is one platform to build, run and govern AI-built software, and our job is to make the hard decisions for you: how changes get reviewed, and how they reach production. You keep building fast. Your whole team can understand what was built and trust it.

That is where we're putting our focus: getting what you build into production, and keeping it trusted once it's there.

In Q3, we made some of our biggest progress yet toward that vision.

From AI-assisted building to a shared way of building

AI agents are becoming part of the development team. But giving everyone an AI coding tool doesn't automatically mean they're building the same way.

With Xano Knowledge, teams can now define the rules, documentation, and repeatable skills they want agents to follow once, and ensure that context is used by everyone.

Your workspace can carry persistent instructions through AGENTS.md, refer to documentation that agents can pull in when needed, and Skills that define how your team performs specific tasks. That same context works with the Xano Agent and with external coding agents through the CLI and Developer MCP.

More importantly, that knowledge belongs to the workspace, not an individual developer's laptop or AI session. It can be reviewed, versioned, and controlled by admins just like the rest of your application.

As more software is built by agents, we think this becomes increasingly important: the way your team builds should belong to your team.

A more complete development lifecycle

We also continued expanding where and how developers can work with Xano.

In Q2, the CLI and Developer MCP opened Xano to external development workflows. In Q3, we extended that workflow to more of the application.

With Static Frontend Hosting through the CLI and MCP, developers and agents can pull, push, and deploy static frontends alongside their backend, making it possible to work across more of an application from tools like Claude Code and Cursor without breaking the Xano development and deployment flow.

We also expanded Sandbox environments so developers and AI agents can create temporary environments across multiple branches and work in parallel without interfering with each other. Changes can be built and tested in isolation before they move forward.

The direction here is simple: the faster software gets created, the more important it becomes to give every change a safe place to exist before it reaches production.

Modernize without starting over

Not every application starts from scratch.

Some of the most important software our customers run today has been built over years, across different languages, services, vendors, and architectures. Replacing all of it rarely makes sense.

With Microservices, teams can now bring existing Docker containers and Helm charts into Xano and call them directly from the Xano function stack. Those services can be monitored from the workspace and included in releases alongside the rest of the Xano application.

That means adopting Xano doesn't have to start with a rewrite.

A team can keep the services that already work, build new APIs and business logic around them, and modernize incrementally. Existing and new software can move through the same release process instead of creating another disconnected stack to operate.

That matters because a platform for AI-built software can't only work for what AI creates tomorrow. It also has to work with the systems your business depends on today.

More control over what reaches production

We made significant progress this quarter on the other side of building: running software in production.

Realtime v2 brings more of the Xano development lifecycle to realtime applications, including authentication and authorization logic, payload validation, branches, Sandbox review, version history, RBAC, Request History, debugging, and rollback.

Teams can now treat realtime logic much more like the rest of their backend instead of operating it as a separate system.

Testing also became easier to understand and act on. Test results now persist, run states are clearer, failures explain more about what went wrong, and the Agent can help create and debug tests.

And underneath all of this, we re-platformed Xano's request execution engine to deliver lower latency, more throughput per instance, and steadier performance under load without requiring customers to change their applications.

These aren't isolated improvements. They're part of the same idea: building quickly only matters if teams can build together, and confidently run what they build.

Build with the AI infrastructure your team chooses

The AI ecosystem is moving too quickly for teams to be locked into a single model or provider.

In Q3, we expanded AI provider support to include OpenRouter, AWS Bedrock, LiteLLM, and Azure Foundry, giving teams more flexibility to use approved models and existing AI infrastructure with Xano Agent and Agents.

For individual developers, model choice is often a preference. For teams, it can also be a question of security, cost, infrastructure, and organizational policy.

Xano should fit into those decisions rather than force teams around them.

The bigger picture

Stepping back, the most important thing about Q3 isn't any single feature.

It's how the pieces work together.

A developer or AI agent can build in the tools they prefer. The team's knowledge and standards can follow them. Multiple builders can work safely in isolated environments. Existing services can become part of the application instead of being rewritten. Tests help validate what changed. Releases create a deliberate path into production. And once software is running, Xano gives the team a shared place to understand and operate it.

That is increasingly what we believe teams need from a backend platform in an AI-first development world.

The ability to generate software will continue getting cheaper and faster. The difficult part will be turning what gets generated into software a team can understand, operate, and confidently put in front of customers.

That's the problem we're building Xano to solve.

Thank you to everyone who built with us, tested these releases, reported issues, and pushed us throughout Q3. Your feedback continues to shape where the platform goes next.

We're excited about what these pieces make possible.

More soon. 🚀

Prakash

It catches things a format check passes, for example 020 7946 0958, a valid-looking UK number from Ofcom's range set aside for drama, or NANPA's 555-0100 to 555-0199 fictitious numbers.

You can try three checks a day on the homepage with no account, and signing up gives you 500 credits. A lookup that establishes no evidence costs nothing; a partial one can be charged.

API docs: https://orisift.com/x?m=post&c=xano-showcase&to=%2Fdocs

I built Orisift. Feedback from anyone running signups in Xano would help.

check password sometimes returns false for users with the correct password, for a few minutes up to an hour, then works again on its own.

- Only accounts with old hashes (created years ago and carried over to our current workspace) are affected.
- Once the password is saved again (new hash), we've never seen it fail.
- Not a code or connection issue. Upgrading the instance didn't help.

About 99% of our users still have old hashes, so this hits almost everyone.

Has anyone seen this? Is there a way to re-hash existing passwords without asking every user to reset?

This has been a headache for us for weeks now, so any pointers would be really appreciated. Thanks!

The main goal was to harden the usual OAuth flow against login-CSRF by adding:

• a 256-bit browser nonce stored in sessionStorage

• signed OAuth state generated by Xano

• provider binding

• 10-minute expiry

• nonce hashing

• verification before the authorization code is exchanged

I tested the flow end to end against both Google and LinkedIn, including:

• wrong nonce

• tampered state

• missing state / nonce

• cross-provider state

• expired state

• replayed authorization codes

The repo includes:

• Xano functions and endpoints

• frontend JavaScript examples

• setup instructions

• architecture diagrams

• threat model

• runtime test cases

GitHub:
https://github.com/jperaleselizondo-hash/secure-xano-oauth

It’s intended as a reference implementation, not an official Xano solution. If anyone here is building custom OAuth flows in Xano, I’d be interested in feedback, edge cases, or improvements.

I'm building a WeWeb front-end on top of Xano, and I'm still fairly new to this side of things, so apologies if I'm missing something obvious.

While profiling our page loads, I noticed that every authenticated API call is preceded by a CORS preflight (OPTIONS request), even for URLs that were just called. To make sure, I ran a clean test: browser cache enabled, navigating page A → page B → page A within 20 seconds. On the second visit to page A, every call was preflighted again for the exact same URL. One endpoint was preflighted three times in 15 seconds. It also happens for a direct XHR POST that doesn't go through WeWeb's service worker.

Each preflight adds roughly 40–80 ms before the actual request (more when the server is busy), and since our calls run one after another, it adds up on every page.

The default preflight response we get looks like this:

Access-Control-Allow-Origin: <echoed origin>

Access-Control-Allow-Headers: *

Access-Control-Max-Age: 86400

Access-Control-Allow-Credentials: true

From what I've read, "*" in Access-Control-Allow-Headers doesn't cover the Authorization header, so browsers accept the preflight but don't reuse it from cache (https://github.com/whatwg/fetch/issues/1278). That would explain what we see, but I may be wrong about the cause.

I tried Custom mode on one API group (Allow-Headers set to "Authorization" and "*"), and ran into two things:

- an origin of "*" seems to be matched literally, so our real origins were rejected (I reverted right away);

- the preflight seems to be answered by the live branch, since OPTIONS requests don't carry the X-Branch header, so changing the setting on a dev branch has no effect on preflights.

So my questions:

1. Has anyone else noticed this? Is it expected with the default CORS configuration?

2. Is there a recommended way to get preflights cached for authenticated requests, without listing every origin on every API group and branch? For example, could Authorization be added to the default Allow-Headers, or could Custom mode reflect the request origin the way Default does?

Thanks a lot for any pointers!

We run Xano instances for multiple clients and are building an internal monitoring dashboard that aggregates error signals across all of them. What we're missing is a supported way to read instance health data: CPU, RAM (API / database / Lambda) and database storage usage.

Today this data is only visible in the Instance Dashboard UI, backed by the internal api:master/instance/{id}/health2 endpoint. We'd rather not build on an undocumented endpoint tied to a personal login session.

What we're asking for: a Metadata API endpoint (for example GET /api:meta/instance/health) that returns the same metrics the dashboard shows, authenticated with a regular access token and its own scope.

This does not need to be real-time. A 5-minute granularity would be more than enough. Our goal is long-term trend monitoring across instances: spotting storage creeping toward capacity, or database RAM climbing week over week, so we can act before an instance goes down rather than after the "Instance Down" e-mail arrives.

Thanks for considering it.

Bas van Ginkel

EsperantoXL

Xano 2.6 speeds up every request and expands what teams can build, connect, test, and release in Xano.

From Microservices that move through the same release path as your Xano application to parallel development environments, more runtime capacity, advanced Realtime, expanded AI provider support, and clearer testing, 2.6 gives teams more room to build without giving up control over what runs in production.

Bring your existing Docker containers and Helm charts into Xano

Run the services you already rely on alongside your Xano application without rewriting what already works. Call them from any workflow and use Xano to orchestrate new logic across your existing systems.

Monitor your microservices from your workspace and include them in tenant releases alongside your Xano application, so everything moves through the same governed deployment workflow without creating a separate release process.

• Explore Microservices documentation

• Watch the Microservices video

Give developers and AI agents their own space to build and test

Use the Xano CLI to create temporary environments across multiple branches so developers and AI agents can work in parallel without interfering with each other’s changes.

That means developers and agents can work against isolated environments at the same time while keeping changes separated until they’re ready.

• Explore CLI Sandbox documentation

Handle more traffic without changing your application

We’ve re-platformed Xano’s request execution which means lower latency, more throughput per instance, and steadier performance under load, with no application changes required.

Build realtime experiences with the control of an API

Validate payloads, use typed path parameters, authorize connections and channel joins, and personalize or redact delivery for each recipient, all with the Xano function stack.

Realtime v2 also works in Tenants and brings drafts, branches, sandbox review, version history, RBAC, request history, debugging, and rollback to realtime logic. Existing Realtime implementations continue to work, so teams can build in v2 alongside a live v1 implementation without disrupting production.

Realtime v2 is available on Essential plans and above.

• Explore Realtime documentation

Use the AI models and providers your team already trusts

Connect OpenRouter, AWS Bedrock, LiteLLM, or Azure Foundry directly to Xano and use approved models and existing AI infrastructure with Xano Agent and Agents.

That gives teams more flexibility over the models and providers they use while continuing to build with AI in Xano.

Know why a test failed and what to fix next

Clearer results and inline failure details make tests easier to understand and act on.

Updates include persistent results, clearer run states, a distinct “Couldn’t run” outcome, and Agent-assisted test creation and debugging, so teams can validate what AI builds and move from failure to action faster.

• Explore Unit Tests and Workflow Testing

Xano 2.6 is ready when you are. Explore the 2.6 release notes for the full release.

Happy building!

Steps to reproduce:                                                                                                                                     

Create a token with extras in a login endpoint:

  var $token_extras {
    value = {role: "Creator", session_version: 1}
}

  security.create_auth_token {
    table = "Users"
    extras = $token_extras
    expiration = 31536000
    id = $Users.id
}

Then, in an auth'd endpoint (auth = "Users"), attempt to read the extras:
debug.stop { value = {extras: $auth.extras, sv: $auth.extras.session_version} }

 Expected: $auth.extras returns {role: "Creator", session_version: 1}

 Actual:
$auth.extras returns [] (empty array).
$auth.extras.session_version returns null.
Only $auth.id is populated.

  Also tested:
  - $auth.session_version → null
  - $auth.iat, $auth.exp, $auth.created → all null
  - util.get_vars and util.get_all_input — neither exposes the token or its metadata

 Use case: We need to implement session invalidation (force-logout on password compromise). I wanted add a session_version in the token extras at login, then compare it against the DB value in auth/me. That way we could increment the session_version (on password change, or in the case of a security incident) when needed. But ewithout readable extras, there's no way to associate a token with any metadata from its creation time, making token revocation impossible without a separate sessions table, which ends up being unnecessarily heavy

 Question: Is this a bug, or are extras intentionally write-only? If the latter, is there any supported way to read token metadata (extras, issued-at timestamp, etc.) inside an API stack?

Any idea when we’ll be able to use more alternatives beyond the current trio?

Thanks

Is anyone else experiencing a recurring crash-loop affecting all background tasks?

Our pattern is very consistent:

- Tasks work normally for around 45 seconds.

- Then all tasks stop for approximately 5 minutes.

- The cycle repeats continuously.

- Our APIs remain online.

- Individual task executions are short, usually under one second.

- There is no long-running task before the crash.

- The dashboard does not show sustained high CPU or memory usage for tasks.

We already upgraded our task processing capacity after a previous recommendation from Xano.

We also significantly reduced the work performed by our tasks. Most of them now only trigger API endpoints and finish immediately. During a previous incident, we disabled and re-enabled tasks individually, but that did not identify any specific task or solve the problem.

The last time this happened, Xano investigated internally and identified Redis resource limits as the cause. They increased our Redis capacity, and the crash-loop stopped. Now the same behavior has returned.

Because detailed Redis metrics are not available in the dashboard, we cannot verify whether Redis is reaching a limit again.

Has anyone experienced the same pattern.. all tasks stopping together while APIs remain healthy and the visible task usage remains below capacity? If so, what was the root cause and how was it permanently resolved?