Documentation

Platform Overview

Nex is not a package manager like NPM or PyPI. Nex is a developer ecosystem platform for sharing modular architecture through Recipe Packages. A Recipe is not a template; it is a config-driven way to add project pieces as if they were written inside the codebase from day one.

What Nex Solves

What is a Recipe?

A Recipe is not a template, and it is not only a complete project structure. It can ship an entire architecture when that makes sense, but the core idea is to break a project into reusable pieces that Nex can add with one command. The recipe config maps files and scripts into the target project so the result feels native, like the developer wrote it there.

• Solves a specific, complex problem (auth, caching, admin dashboards)
• Can be a focused feature slice or a full architecture
• Comes with files, scripts, variants, and setup mapping
• Integrates into your project — fully modifiable after install
• Each recipe is backed by its own developer-owned GitHub repo

✓ Full Authentication System (JWT + bcrypt)
✓ Complete Admin Dashboard Backend
✓ Database Connection + ORM Setup
✓ Real-time Chat Infrastructure
✓ Security Headers Middleware

Install the CLI

The Nex CLI (xnex) is distributed as a standalone executable installer. Follow these simple steps to install it on your machine:

1. Download the installer — Go to the Download page and download the installer executable suitable for your operating system.
2. Run the installer — Locate the downloaded installer file (e.g., nex-installer.exe) and double-click it to begin installation.
3. Global registration — The installer will automatically configure the environment and register xnex as a global command, allowing you to run it from any terminal directory.

Once the installation is complete, open a terminal and confirm everything is working by running:

xnex xhelp

If the command is not recognized, simply restart your terminal window so your system can pick up the updated PATH.

CLI Commands

Setup

Recipes

Execution

Publishing

CLI Login

The login command allows you to authenticate your developer account directly from the terminal. This sets up your local configuration so you can interact with the registry and publish recipes.

Before running this command, you need to have already created a developer account on the Nex platform. The CLI authenticates against that existing account — it does not create one for you.

xnex login

Authentication Flow

1. Run the command — Execute xnex login in your terminal.
2. Provide email — You will be prompted to enter your registered account e-mail address.
3. Provide password — Next, you will be prompted to enter your account password.
4. Verification — The CLI verifies the credentials against the Nex authentication service.
5. Success — Upon successful verification, you will be logged into your developer account, and your API token will be saved locally.

On successful login, your Nex token is saved automatically — this is the same token used by xnex config nex <token>, so there is no need to run that command manually after logging in.

GitHub Token

To publish recipes, you also need to connect a GitHub classic personal access token. This is separate from your Nex login and is required because each recipe is backed by its own developer-owned GitHub repository.

Getting a classic token

1. Open GitHub settings — Go to GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic).
2. Generate a new token — Select Generate new token (classic) and choose the scopes your recipe publishing needs (typically repo access).
3. Copy the token — GitHub only shows the token once, so copy it immediately.

Setting the token

xnex config github <token classic>

Your GitHub token is encrypted and stored locally on your device only. It is never sent to, or used by, anything other than GitHub's own API — Nex does not transmit or store it on any other server.

Install a Recipe

The installation flow is designed for transparency and control:

1. Select target — Use xnex install <recipe> for recipes
2. Review structure — CLI previews the files that will be written into your project
3. Approve changes — Confirm file writes before anything is applied
4. Allow scripts — If scripts exist, explicitly allow them before execution
5. Integrate — Files land where the recipe config maps them inside the project

PS C:\project> xnex install auth-system-pro
📦 Nex Installer
info Selected recipes: auth-system-pro

📦 Processing auth-system-pro...
📦 Recipe file structure:
├─ 📁 src
└─ 📁 recipes

Do you want to apply these changes to your project? (y/n): y
✔ Applying changes...

✨ All operations completed successfully.

For local development recipes, the same flow can use linked artifacts such as xnex install my-recipe@link.

Script Approval

If a recipe defines setup scripts, the CLI always shows the full list of scripts before running anything. You are then asked to type I allow all scripts to confirm execution. Once entered, every script runs automatically in order, and you see each command's output live in your terminal as it runs.

If you don't type the confirmation phrase, the CLI offers a second option: approving scripts one by one. If you accept this, the CLI asks for confirmation before running each individual script, rather than running them all at once.

Run Scripts & Tree

The current CLI also exposes execution and structure helpers for existing Nex configs:

xnex run start
xnex run my-recipe::setup
xnex tree

• xnex run <name> runs a script defined in nexconfig.json or a recipe
• xnex tree generates the config-driven file structure view
• xnex link links the current recipe locally for development

Publish a Recipe

The currently verified publish entry point is xnex publish. Before publishing, configure the required tokens with the config command.

• Nex token — Filled in automatically when you run xnex login; you don't need to set it manually with xnex config nex <token> unless you want to override it.
• GitHub token — Set it with xnex config github <token classic>. See GitHub Token for how to generate one.

xnex config github YOUR_GITHUB_TOKEN
xnex publish

First Steps: Structuring a Recipe

Before publishing, a recipe needs a nexconfig.json and its files laid out correctly. Run this from inside your existing recipe directory:

xnex init <package name>

This command does not create a new folder for you — it runs inside a recipe directory you already have, and generates a nexconfig.json file along with a recipes/<recipe name> folder.

From there, add your recipe's files or folders to the files array in nexconfig.json. Once that's populated, run xnex tree to have the setup.files mapping generated automatically. Note that xnex tree will not run if files is empty.

Help & Workflow

Recipe discovery currently belongs to the Explorer experience, while CLI command discovery is exposed through help output:

xnex xhelp
xnex xhelp install
xnex install --help
xnex run --help

Running xnex xhelp on its own prints a short summary of every available command. Passing a command name, such as xnex xhelp install or xnex xhelp publish, prints detailed help for just that command.

nexconfig Schema

Every recipe includes a configuration file defining how files, scripts, and variants are integrated into a project:

{
  "name": "auth-system-pro",
  "version": "1.0.0",
  "description": "Production-ready JWT authentication",
  "keywords": [
    "auth",
    "jwt"
  ],
  "files": [
    "src/auth/",
    "src/middleware/"
  ],
  "setup": {
    "scripts": [
      "npm install bcryptjs jsonwebtoken"
    ],
    "files": {
      "src/auth/": {
        "auth.service.js": "src/auth/auth.service.js"
      }
    }
  }
}

Setup Object

The setup object defines the config-driven integration behavior:

setup.files

A recursive file tree mapping source paths to destination paths in the user's project.

setup.scripts

An array of shell commands executed during integration (with user approval).

setup.variants

An optional list of alternative configurations for the same recipe, letting a developer choose which extra files get added on top of the base setup depending on what they need. Each variant has its own name, description, and setup.files mapping, so a single recipe can offer several interchangeable options — for example, a UI component recipe might offer variants like "basic", "glass", or "neon" styles of the same component, each shipping a different source file to the same destination.

Script Security

Nex uses multi-level approval to prevent malicious script execution: