# Nexior: a self-hostable AI app that wraps chat, image, video and music behind one Vue frontend

> Nexior is an MIT-licensed Vue 3.5 and Capacitor app that puts 40+ models across four modalities behind one UI, with BYOK or a single AceData key. It ships its own user accounts, payments and referral system, which is the part that decides whether you want it.

**AceDataCloud/Nexior** — Consumer AI app for chat, image generation, video generation, and music creation powered by Ace Data Cloud APIs.

- Repository: https://github.com/AceDataCloud/Nexior
- Website: https://studio.acedata.cloud
- Stars: 397 · Forks: 524
- Language: Vue
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/acedatacloud-nexior

## The problem Nexior targets: four modalities, one frontend, no backend to build

Anyone building an AI product faces the same wiring problem. Chat runs through one vendor's SDK, image generation through another, video through a third, music through a fourth. Each has its own auth, its own request shape, its own billing. The README frames Nexior as the answer: an app that puts ChatGPT, Claude, Gemini, Grok, DeepSeek and Kimi alongside Midjourney, Flux, Suno, Veo, Kling, Hailuo and Wan behind a single interface, self-hosted or shipped as your own product.

The intended audience is specific. It is not a library for calling models from code. It is a consumer-facing application, with a UI, user accounts and payments, aimed at someone who wants a working product rather than an SDK. The README describes it as an "AI-SaaS starter" and notes that every deployment ships with email login, payments and a referral system that binds registered users to the site owner. That framing matters more than the model list, because it tells you the project is opinionated about the business layer, not just the UI.

The project is built by AceDataCloud and powers the live app at studio.acedata.cloud. The repository is not archived; the last push was on 2026-08-26, and the most recent release listed is @acedatacloud/nexior_v3.367.2 on the same date. Version numbers in this range, with releases days apart, indicate a fast cadence. Treat that as a fact about the release history, not a promise about the next six months.

## How the Vue 3.5 and Capacitor stack is put together

The stack is stated plainly: Vue 3.5, Vite 7, TypeScript, Vuex 4 with per-service namespaced modules, Element Plus, Capacitor 6 for iOS and Android, and OAuth SSO. The per-service namespaced Vuex modules are the interesting detail. They imply one store module per AI service, which is how a codebase keeps chat, image, music and video state from colliding as the model list grows.

The repository layout confirms the surface split. There are android/, ios/ and electron/ directories alongside src/, plus capacitor.config.ts and electron-builder.yml. The package.json scripts show how each surface is built: build:web, build:android, build:ios and build:electron each set a VITE_SURFACE environment variable before running Vite, and pack:android and pack:ios follow the build with npx cap copy. So the same source tree produces a web bundle, a Capacitor shell and an Electron desktop build, selected at build time rather than runtime.

The Dockerfile reveals a deliberate deployment design that the README does not discuss. It builds with npm run build:ssg, then runs scripts/ssg-shell.mjs, copies the emitted assets, and asserts two limits: no more than 4000 files and no more than 268435456 bytes. A later bridge stage merges previous assets with current ones, refuses to overwrite a file whose contents differ ("conflicting immutable asset"), and caps the combined set at 8000 files and 536870912 bytes. That is cache-invalidation engineering for a static frontend served by nginx, and it tells you the maintainers treat asset immutability as a hard constraint. If your build produces more than 4000 asset files, the image build fails rather than warns.

## Installing Nexior with Docker and getting to a first request

The README gives three install paths. The Docker route is the one to start with because it does not require a Vercel account and it exposes a known port. Clone the repository, copy the environment template, then bring the stack up:

```bash
git clone https://github.com/AceDataCloud/Nexior.git
cd Nexior
cp .env.example .env
```

The README says to set your AceData key (or BYOK provider keys) in that file. It does not list the individual variable names, so open .env.example and read it directly rather than guessing. Then start the container:

```bash
docker compose up -d
```

The README states the app is then reachable at http://localhost:8084. Note the discrepancy worth checking before you file a bug: the docker-compose.yaml in the repository maps port 8080 to container port 80, while the README's quick start says 8084. Confirm which one your checkout actually exposes, because the two sources disagree.

If you would rather not run Docker, the local development path is three commands and no container:

```bash
npm install
cp .env.example .env.local
npm run dev
```

The dev script is vite --host, so it binds beyond localhost, which matters if you are testing from a phone on the same network. Keys come from platform.acedata.cloud, which the README says offers a free quota, and the README points to docs/deploy/ for the full guides. That directory exists in the repository listing, so it is the right place to look when the quick start runs out of detail.

## Where Nexior stops being the right tool

The largest limitation is architectural. Nexior is a frontend. The Dockerfile's final stages copy a Vite build into nginx and serve it as static files. There is no application server in this repository, no database schema, no migration directory. The user system, payments and referral binding described in the README therefore depend on a backend the repository does not contain. Self-hosting the UI is not the same as self-hosting the accounts and the money, and the README does not explain where that boundary sits.

The second limitation is provider coverage. The README claims BYOK support, but the repository listing does not include a documented matrix of which provider keys map to which models, and the README's quick start does not name a single BYOK environment variable. If your plan is to run chat on your own OpenAI key and video on your own Kling key, you are reading .env.example and the source to find out whether that combination is wired up. The one-key AceData path is the documented one; BYOK is asserted rather than specified.

The third is release discipline. Releases listed include v3.367.2, v3.367.1 and v3.364.1 within a week, and the package.json version is 3.371.1, ahead of the newest listed release. That cadence is fine for a consumer app that redeploys continuously. It is awkward if you pin a version and expect a stable surface across months, because the minor number moves constantly and the changelog lives in CHANGELOG.json and CHANGELOG.md rather than in the README.

Finally, the README's own framing should give a technical evaluator pause. It asks readers to star the repository, describes itself as "revenue-ready," and devotes a section to the referral mechanism. That is marketing copy for a product, and it means the README is a poor substitute for the docs/deploy/ guides when you need configuration truth.

## Nexior compared with building on LibreChat or Open WebUI

The obvious alternative class is the self-hosted chat frontend: LibreChat and Open WebUI both put multiple chat providers behind one interface and both are open source. The difference is scope, and it cuts both ways.

Those projects concentrate on chat. Their configuration surface is provider endpoints and API keys, and their deployment model is a server you run that holds conversation state. Nexior spreads across four modalities, and its README lists image, music and video models that a chat-only frontend does not attempt. If you need Suno or Veo in the same product as your chat, a chat-only tool means a second application and a second login.

The cost of that breadth is that Nexior's default path routes through AceData's platform rather than through per-provider configuration. A chat frontend that asks only for an OpenAI base URL and key is simpler to reason about and simpler to audit. Nexior asks you to accept a platform relationship, or to do the undocumented work of wiring BYOK yourself. Neither choice is wrong; they answer different questions. Pick Nexior when the four modalities in one app is the requirement. Pick a chat-only frontend when provider independence and a server you fully control is the requirement.

## Licence, maintenance and the cost of staying current

The licence is MIT, stated in the README and present as LICENSE at the repository root. That permits forking, rebranding and commercial distribution, which is consistent with the README's invitation to "fork it, brand it, ship it." MIT does not resolve the questions that matter commercially: what terms govern the AceData API you call, what happens to user data once the app is deployed, and whether the referral payout mechanism has its own agreement. Those are separate documents, and this repository does not contain them. This is not legal advice; read the AceData platform terms before you put paying users on it.

Maintenance signals are mixed but readable. The repository is not archived. The last push was on 2026-08-26, and the release list shows three versions in the final week of that month. The tooling around releases is real: beachball.config.js drives the change, verify, bump and release scripts, husky runs prepare, and there is an e2e/ directory with playwright.config.ts and a test:e2e:desktop script. A project with a release manager, a changelog generator and end-to-end tests is being run as a product, not abandoned.

The upgrade cost is the part to weigh. The Dockerfile's bridge stage exists precisely because assets are treated as immutable and old ones must survive a new deploy, with a hard failure on content conflicts. That is good engineering for cache correctness and a real constraint for you: if you patch a file in dist/assets and redeploy, the bridge stage will detect the changed content and abort the build. Customisation belongs in src/ and in the build, not in the served output. The version numbers moving several times a week also mean you should decide early whether you track main or pin a tag, because the gap between the two widens quickly at this cadence.

## Conclusion

Adopt Nexior if you want a single frontend over many providers and you accept that the default path runs through AceData's platform; the docker compose file and the MIT licence make trying it cheap. Skip it if you need a backend you control, a documented provider matrix, or a project whose release cadence you can predict. Before committing, read docs/deploy/, check whether .env.example lists the BYOK provider keys you actually hold, and confirm the image reference ghcr.io/acedatacloud/studio-frontend resolves for the BUILD_NUMBER you plan to pin.

## FAQ

### What is Nexior and who is it for?

Nexior is an MIT-licensed, self-hostable AI application that puts chat, image, music and video models behind one interface, built with Vue 3.5 and Capacitor so the same codebase targets web, iOS and Android. The README positions it for people who want to deploy their own AI product rather than call models from code, and it ships user accounts, payments and a referral system as part of the deployment.

### How do I install and run Nexior with Docker?

Clone the repository, copy .env.example to .env and set your AceData key or BYOK provider keys, then run docker compose up -d. The README states the app is available at http://localhost:8084, though the docker-compose.yaml in the repository maps port 8080 to container port 80, so verify which port your checkout exposes.

### Does Nexior support BYOK, or do I have to use an AceData key?

The README says both are supported: bring your own provider keys, or use a single AceData key for all models. The documented quick start only describes setting an AceData key, and the README does not name the individual BYOK environment variables, so check .env.example for the keys your providers require.

### Can I self-host Nexior without running my own backend?

The repository builds a static frontend served by nginx, and it contains no application server or database schema. The README describes user accounts, payments and referral binding as part of every deployment, which implies a backend hosted elsewhere, so self-hosting the UI and self-hosting the accounts are not the same thing.

## Sources

- [Official documentation](https://studio.acedata.cloud)
- [Official README](https://github.com/AceDataCloud/Nexior#readme)
- [Project repository](https://github.com/AceDataCloud/Nexior)
- [Release notes](https://github.com/AceDataCloud/Nexior/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/acedatacloud-nexior