Enterprise
Deploying and governing Neuralis — and the AI workforce inside it — for an organization.
Maturity: stable (85 %)
Enterprise security and governance. Every request, from a person, an agent, a skill script, a scheduled run or an external MCP client, passes the same deny-by-default layers: one session identity, project membership, role and feature grants, path policy, package trust and audit.
- Give the host access plane only to a single trusted operator's machine.
- A package added to the host dependencies runs with full first-party trust; vet it like any dependency.
- Login lockout is kept per process; a multi-node deployment gets proportionally more login attempts.
- Encrypted credentials depend on the master key file; back it up with the data directory.
Maturity: stable (85 %)
Sign-in. Users sign in with email and password, sessions end the moment a user is disabled or removed, and external MCP clients sign in through OAuth.
- Single sign-on (OIDC, SAML) is not available; sign-in is email and password.
- Behind a reverse proxy, declare it in NEURALIS_TRUSTED_PROXIES so login rate limits see the real client address.
- Login lockout is kept per process; a multi-node deployment gets proportionally more login attempts.
This section is for the people who run Neuralis rather than just use it: platform administrators, DevOps engineers, and security reviewers.
The premise of the platform is that AI agents do real work — they hold files, run shell commands, drive desktops, fire on schedules, and spend money. An organization can only let that happen if agents are governed at least as strictly as employees, so Neuralis applies one control plane to both: the same projects, the same roles and feature grants, the same path policies, spend limits, and audit trail, whether the caller is a person in a browser, an agent mid-stream, a skill script, or an external MCP client. A scheduled workflow runs as the human who created it, with that human's current rights — there is no system identity to hide behind.
Neuralis is designed for the deployment shape where an organization installs one instance on-prem or in a private cloud, an admin configures it, and employees sign in as ordinary users — it is multi-tenant, scoped, and deny-by-default out of the box, not as an optional hardening mode. Your models, your data, and your audit log stay on your infrastructure.
Three properties define the operating model:
- Admin-configured. Registration is closed; user accounts are created by the setup script or through the admin API. Model providers, runtime settings, and secrets are managed centrally — see configuration and credentials.
- Multi-tenant by default. Projects are the isolation boundary: every agent, conversation, source, and package enablement is project-scoped, and non-members cannot even infer that a project's resources exist. See multi-tenancy.
- Deny by default. Every request — from a human in the browser, an agent tool call, a skill script, or an external MCP client — passes the same six security layers. The full story lives on the security model page.
Section map
Deployment
The Docker stack, the native-Node alternative, runtime topology, persistence, and health checks.
Configuration
The three configuration tiers — boot-critical .env, the runtime platform config store, and the credential store — plus model provider setup.
Multi-tenancy
Projects as the tenancy boundary: membership, isolation guarantees, spend limits, per-project packages, and agent scoping.
Security model
The six layers every request passes through, the single session identity, and how secrets are handled.
Roles and features
Built-in and custom roles, feature grants, role priority, and how packages contribute features.
Credentials
The encrypted credential store: four scopes, most-specific-wins resolution, and how skills receive secrets.
Administration and audit
Day-to-day operation through the admin dashboard, usage analytics, the audit log, and maintenance operations.
MCP access
Connecting external MCP clients: the hosted endpoint, OAuth 2.1 and API keys, and the boundary rules.
If you are evaluating Neuralis rather than deploying it yet, start with core concepts for the platform vocabulary, then return here for the operational details.