Introduction to AxHub
What AxHub is, and how apps, deploys, and visibility fit together — start here
AxHub is a platform for building, deploying, and operating apps inside your company. Push code to GitHub and it builds and runs on its own, with a unique address — and login (SSO), data, and visibility are all managed in one place.
No complex server setup or infra knowledge needed: just push code and an internal service comes up. You can also connect a database your company already uses and read its data straight from your app.
What you can do with AxHub
- Create apps — pick a template and go from GitHub repo to first deploy in one flow.
- Deploy — push code to GitHub and it builds and runs. Check status and logs; cancel or roll back.
- Work with data — create tables without code and read/write them from your app.
- Connect company data — connect a database your company uses to your app and pull its data in directly.
- Manage visibility and access — decide who can see the app (you only / some / everyone) and manage member roles.
- Wire up login — when a user signs in with their company account, your app receives who they are via headers. You don't implement auth yourself.
You usually drive AxHub with the CLI (axhub) or the Claude Code plugin. You can also create and manage apps from the web console.
Key terms
| Term | Meaning |
|---|---|
| Company | Every app, member, and dataset is scoped to a company. Resources never mix across companies. |
| App | The unit of deployment. It has a unique address (subdomain), a visibility, and a status. |
| Deployment | The result of building and running code you pushed to GitHub. Each commit makes a new deployment. |
| Data table | The database your app uses. Create, read, and write it like a spreadsheet — no code needed. |
| Environment variables | App config and secrets. Managed with axhub env set. |
| Members & roles | Define who can do what inside the company. |
Understanding app status
An app has three separate states that move independently. This is the most common source of confusion, so keep them distinct.
| State | Values | Meaning |
|---|---|---|
| Deploy status | Not deployed · Deployed · Archived | Whether code is actually running. It stays "Not deployed" until the first successful deploy, which flips it to "Deployed" automatically. |
| Visibility | Only me · Some people · Everyone | Who can see the app. Even "Everyone" means company-wide only. |
| Operating status | Live · In development · Archived | A display-only state derived automatically from the values above plus review. This is the badge you see in the console and lists. |
To become "Live", two things are both required — ① review approval, and ② visibility set to Everyone or Some people. Even if approved, an "Only me" app stays In development, not Live. Only Live apps appear in Browse (the store). So a deployed app can still read as "In development" if it is not yet public — deploy status and operating status are separate.