Self-Hosting

Core

Authentication (OAuth sign-in)

AI / LLM (chat builder + action.ai steps)

Without an LLM key, workflows can still be deployed and executed via the API, SDK, or MCP — as long as they don't include action.ai steps. The LLM is needed for the chat builder and any workflow step that makes an in-workflow LLM call.

1. Platform authentication (signing into S6S)

These let users log into the S6S dashboard via Google or GitHub OAuth. Optional — you can skip this entirely with S6S_AUTH_DISABLED=true for internal use or use email/password auth.

To enable Google sign-in, create an OAuth 2.0 Client ID in the Google Cloud Console and set the callback URL to:

http://localhost:3000/api/auth/google/callback
# In production, replace with your S6S_BASE_URL:
https://workflows.mycompany.com/api/auth/google/callback

GitHub sign-in follows the same pattern — create an OAuth App in GitHub Developer Settings with callback URL {S6S_BASE_URL}/api/auth/github/callback.

2. Integration OAuth (connecting external services)

When a workflow needs to call Google Drive, Slack, YouTube, etc., users connect their accounts via OAuth. As a self-hoster, you need to create your own OAuth app for each service your users want to connect.

S6S uses a naming convention for integration OAuth env vars:

# Google integrations (Drive, Sheets, YouTube)
# Same credentials as Google sign-in — just enable
# additional scopes in the OAuth consent screen.
OAUTH_GOOGLE_CLIENT_ID=your-client-id
OAUTH_GOOGLE_CLIENT_SECRET=your-client-secret

# Slack
OAUTH_SLACK_CLIENT_ID=your-client-id
OAUTH_SLACK_CLIENT_SECRET=your-client-secret

# General pattern:
# OAUTH_{PROVIDER}_CLIENT_ID=...
# OAUTH_{PROVIDER}_CLIENT_SECRET=...

If a user tries to connect a provider that is not configured, S6S returns a clear error message indicating which environment variable to set.

Note: Google sign-in and Google integrations share the same OAUTH_GOOGLE_* credentials. Make sure your OAuth app has the right scopes enabled (Drive, YouTube, Sheets) in the Google Cloud Console under "OAuth consent screen".

3. API key credentials (user-managed)

Many integrations (Buffer, Telegram, Notion, OpenAI, etc.) use API keys instead of OAuth. Users paste their own API keys into the S6S credentials page at /credentials, and S6S stores them encrypted with your S6S_CREDENTIAL_ENCRYPTION_KEY.

This requires no configuration from you as a self-hoster — it is entirely user-managed. When a workflow is deployed that needs credentials, the deploy response includes missing_credentials with a connect_url and setup instructions for each provider.

4. LLM keys (chat builder + action.ai)

S6S uses an LLM for two things: the chat workflow builder (natural-language UI for creating workflows) and action.ai steps that make in-workflow LLM calls (e.g. summarize, classify, extract). Configure via environment variables or the Settings UI at /settings.

Without an LLM key, workflows that don't use action.ai steps can still be deployed and executed via the API, SDK, or MCP.

Prerequisites

• Node.js 22+
• pnpm 10+
• PostgreSQL 14+

Step-by-step

# Clone and install
git clone https://github.com/Sawan6/S6S-ai.git
cd S6S-ai
pnpm install

# Configure environment
cp .env.example .env
# Edit .env — set DATABASE_URL to your PostgreSQL instance

# Run database migrations
npx tsx scripts/auto-migrate.ts

# Build all packages
pnpm -r build

# Seed demo workflows (optional)
pnpm db:seed

# Start the API server (port 3000)
pnpm dev:web

# In a separate terminal, start the worker daemon
pnpm worker:daemon

Both the API server and the worker daemon must be running for workflows to execute. In production, run them as separate processes or systemd services.

Worker configuration

Connecting to an external database

To use a managed PostgreSQL instance (e.g. Supabase, Neon, RDS), set DATABASE_URL in your environment:

DATABASE_URL=postgresql://user:password@host:5432/s6s?sslmode=require

Running migrations manually

npx tsx scripts/auto-migrate.ts

In Docker Compose, migrations run automatically on container startup.