High availability

Oxygen is built so the things you and your team do all day — asking questions, viewing answers, opening dashboards — keep working through deploys, maintenance, and the occasional node restart. A smaller set of developer actions are handled by a single dedicated environment and pause for a few seconds when it restarts, then resume on their own. This page explains exactly what falls into each bucket, what you’ll see during a restart, and why your data is never at risk.

​

Always available

These run on a redundant, horizontally-scaled fleet. There’s no single point of failure, they scale with your traffic, and a node restarting or being replaced is invisible to you:

• Asking questions and viewing answers — the chat experience and your results.
• Opening past conversations — your full history, any time.
• Dashboards and Data Apps — viewing them and their last computed data.
• Browsing agents, procedures, apps, and the semantic layer.
• Running queries against your connected warehouse.
• Charts you’ve already viewed, query results, and saved files.
• Sign-in, settings, members, billing, and API keys.

​

Briefly pauses during a restart

These are handled by the developer environment (Oxygen Factory) — a single dedicated instance that owns your project’s working files and runs new computations:

• Editing project files and Git actions (commit, branch, push, pull).
• Compiling and publishing changes you’ve made.
• Running a new analysis or refreshing a Data App’s data.
• Modeling (Airform / dbt) actions.

When the developer environment restarts — during a deploy or maintenance — these pause for a few seconds. The app shows a calm notice rather than an error:

Oxygen Factory is temporarily unavailable. File editing, Git, and live app runs are paused right now. Chat and your saved data keep working.

The action resumes automatically once the environment is back; you can also retry. Nothing is lost.

​

Your data is never at risk

The source of truth for your project is your Git repository plus Oxygen’s managed database and object storage — all durable and backed up. The developer environment’s local copy is only a fast-access cache: if it restarts, it rebuilds itself from Git. A restart can never lose committed work.

​

What you’ll see during a deploy or restart

Deploys are rolling: the serving fleet stays up the whole time, and the developer environment restarts briefly at the end.

​

Deploying Oxygen for high availability

Oxygen separates into independently-scaled roles so you can make the high-traffic path redundant:

• Serving fleet — stateless replicas that handle all the always-available work above. Run two or more behind a load balancer and scale them with traffic; any replica can serve any request, so losing one is harmless.
• Developer environment — a single instance that owns the working files and runs computations. It recovers by restarting and re-cloning from Git (its disk is a cache, not the source of truth). Keep its restarts short; the serving fleet keeps the product up while it does.
• Workers — background processors (compiles, schedules, monitors) that scale independently of the serving fleet.

This is the same split that lets cloud platforms keep a deployed app online while a build runs separately: the part everyone uses is replicated and elastic, and the single build/edit environment is isolated so its restarts don’t take the product down.