Enterprise

SteelEngine Enterprise provides advanced features for organizations with enhanced security, compliance, and management requirements.

Access Control

Permission groups collect people and can receive PBAC role assignments at organization or workspace scope. Enterprise feature restrictions can additionally limit which models, blocks, and platform features group members can use.

Features

Allowed Model Providers - Restrict which AI providers users can access (OpenAI, Anthropic, Google, etc.)
Allowed Blocks - Control which workflow blocks are available
Platform Settings - Hide Knowledge Base, disable MCP tools, disable custom tools, or disable invitations

Setup

Navigate to Organization Settings → Access → Groups.
Create a permission group and add members.
Assign one or more seeded or custom roles to the group at organization or workspace scope.
Configure any model, block, or platform-feature restrictions.

Not belonging to a group does not imply full access. PBAC roles and assignments always determine resource authority. Enterprise group restrictions are an additional product-feature filter enforced in the UI and at execution time.

Single Sign-On (SSO)

Enterprise authentication with SAML 2.0 and OIDC support for centralized identity management.

Supported Providers

Okta
Azure AD / Entra ID
Google Workspace
OneLogin
Any SAML 2.0 or OIDC provider

Setup

Navigate to Settings → SSO in your workspace
Choose your identity provider
Configure the connection using your IdP's metadata
Enable SSO for your organization

Once SSO is enabled, team members authenticate through your identity provider instead of email/password.

Self-Hosted Configuration

For self-hosted deployments, enterprise features can be enabled via environment variables without requiring billing.

Environment Variables

Variable	Description
`ORGANIZATIONS_ENABLED`, `NEXT_PUBLIC_ORGANIZATIONS_ENABLED`	Enable team/organization management
`ACCESS_CONTROL_ENABLED`, `NEXT_PUBLIC_ACCESS_CONTROL_ENABLED`	Permission groups for access restrictions
`SSO_ENABLED`, `NEXT_PUBLIC_SSO_ENABLED`	Single Sign-On with SAML/OIDC
`CREDENTIAL_SETS_ENABLED`, `NEXT_PUBLIC_CREDENTIAL_SETS_ENABLED`	Polling Groups for email triggers
`DISABLE_INVITATIONS`, `NEXT_PUBLIC_DISABLE_INVITATIONS`	Globally disable workspace/organization invitations

Organization Management

When billing is disabled, use the Admin API to manage organizations.

The Admin API addresses orgs and workspaces by their internal UUIDs ({orgId}, {workspaceId}), not by the URL slugs. UUIDs are stable across renames; slugs are not. The user-facing dashboard URLs (/{orgSlug}/{workspaceSlug}/...) and the Admin API are deliberately separate — see Organizations and Workspaces for the full slug-vs-UUID model.

# Create an organization
curl -X POST https://your-instance/api/v1/admin/organizations \
  -H "x-admin-key: YOUR_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "My Organization", "ownerId": "user-id-here"}'

# Add a member
curl -X POST https://your-instance/api/v1/admin/organizations/{orgId}/members \
  -H "x-admin-key: YOUR_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"userId": "user-id-here", "role": "admin"}'

Workspace Members

When invitations are disabled, use the Admin API to manage workspace memberships directly:

# Add a user to a workspace
curl -X POST https://your-instance/api/v1/admin/workspaces/{workspaceId}/members \
  -H "x-admin-key: YOUR_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"userId": "user-id-here", "roleKey": "workspace:write"}'

# Remove a user from a workspace
curl -X DELETE "https://your-instance/api/v1/admin/workspaces/{workspaceId}/members?userId=user-id-here" \
  -H "x-admin-key: YOUR_ADMIN_API_KEY"

Notes

Enabling ACCESS_CONTROL_ENABLED automatically enables organizations, as group access management requires organization membership.
When DISABLE_INVITATIONS is set, users cannot send invitations. Use the Admin API to manage workspace and organization memberships instead.

Common Questions

The Docker Compose production setup includes the SteelEngine application (8 GB memory limit), a realtime collaboration server (1 GB memory limit), and a PostgreSQL database with pgvector. A machine with at least 16 GB of RAM and 4 CPU cores is recommended. You will also need Docker and Docker Compose installed.

Yes. SteelEngine supports Ollama and VLLM for running local AI models. A separate Docker Compose configuration (docker-compose.ollama.yml) is available for deploying with Ollama. This lets you run workflows without any external API calls, keeping all data on your infrastructure.

When self-hosted, all data stays on your infrastructure. Workflow definitions, execution logs, credentials, and user data are stored in your PostgreSQL database. If you use local AI models through Ollama or VLLM, no data leaves your network. When using external AI providers, only the data sent in prompts goes to those providers.

Self-hosting SteelEngine requires an Enterprise subscription. Contact sales@steelengine.com for pricing and deployment options.

SteelEngine supports SAML 2.0 and OIDC protocols, which means it works with virtually any enterprise identity provider including Okta, Azure AD (Entra ID), Google Workspace, and OneLogin. Configuration is done through Settings in the workspace UI.

Use the Admin API with your admin API key. Workspace membership requests use a roleKey such as workspace:write or a custom role key; the tier-style permissions field is rejected. Organization membership and workspace role assignment are separate operations.

The Docker Compose setup is designed for single-node deployments. For production scaling, you can deploy on Kubernetes with multiple application replicas behind a load balancer. The database can be scaled independently using managed PostgreSQL services. Redis can be configured for session and cache management across multiple instances.

A group can receive PBAC role assignments, so members inherit the group's resource permissions at the assignment scope. Enterprise restrictions can also narrow available model providers, workflow blocks, and platform features. Both layers are enforced; a feature restriction never grants a missing PBAC permission.

Enterprise

Common Questions

On this page