Multiple Instances

Run multiple nanoinfra instances simultaneously with separate configs and runtime data. Use --config as the main entrypoint. Optionally pass --workspace during onboard when you want to initialize or update the saved workspace for a specific instance.

Quick Start

If you want each instance to have its own dedicated workspace from the start, pass both --config and --workspace during onboarding.

Initialize instances:

# Create separate instance configs and workspaces
nanoinfra onboard --config ~/.nanoinfra-telegram/config.json --workspace ~/.nanoinfra-telegram/workspace
nanoinfra onboard --config ~/.nanoinfra-discord/config.json --workspace ~/.nanoinfra-discord/workspace
nanoinfra onboard --config ~/.nanoinfra-slack/config.json --workspace ~/.nanoinfra-slack/workspace

Configure each instance:

Edit ~/.nanoinfra-telegram/config.json, ~/.nanoinfra-discord/config.json, etc. with different channel settings. The workspace you passed during onboard is saved into each config as that instance's default workspace.

Run instances:

# Check one instance before starting it
nanoinfra status --config ~/.nanoinfra-telegram/config.json

# Instance A - Telegram bot
nanoinfra gateway --config ~/.nanoinfra-telegram/config.json

# Instance B - Discord bot
nanoinfra gateway --config ~/.nanoinfra-discord/config.json

# Instance C - Slack bot with custom port
nanoinfra gateway --config ~/.nanoinfra-slack/config.json --port 18792

Path Resolution

When using --config, nanoinfra derives its runtime data directory from the config file location. The workspace still comes from agents.defaults.workspace unless you override it with --workspace.

To open a CLI session against one of these instances locally:

nanoinfra agent -c ~/.nanoinfra-telegram/config.json -m "Hello from Telegram instance"
nanoinfra agent -c ~/.nanoinfra-discord/config.json -m "Hello from Discord instance"

# Open the browser workbench for a specific instance
nanoinfra webui -c ~/.nanoinfra-telegram/config.json

# Optional one-off workspace override
nanoinfra agent -c ~/.nanoinfra-telegram/config.json -w /tmp/nanoinfra-telegram-test

nanoinfra agent starts a local CLI agent using the selected workspace/config. It does not attach to or proxy through an already running nanoinfra gateway process.

Component	Resolved From	Example
Config	--config path	~/.nanoinfra-A/config.json
Workspace	--workspace or config	~/.nanoinfra-A/workspace/
Cron Jobs	workspace directory	~/.nanoinfra-A/workspace/cron/
Media / runtime state	config directory	~/.nanoinfra-A/media/

Two consequences are worth stating. Each instance needs its own port if they run at the same time. A separate workspace per instance is what makes memory, sessions and skills isolated.

Minimal Setup

1. Copy your base config into a new instance directory.
2. Set a different agents.defaults.workspace for that instance.
3. Start the instance with --config.

Example config fragment:

{
  "agents": {
    "defaults": {
      "workspace": "~/.nanoinfra-telegram/workspace"
    }
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "token": "YOUR_TELEGRAM_BOT_TOKEN"
    }
  },
  "gateway": {
    "host": "127.0.0.1",
    "port": 18790
  }
}

The copied base config can keep using the same modelPresets and agents.defaults.modelPreset. If this instance needs a different model, add another preset and set agents.defaults.modelPreset to that preset name.

Start separate instances:

nanoinfra status --config ~/.nanoinfra-telegram/config.json
nanoinfra gateway --config ~/.nanoinfra-telegram/config.json
nanoinfra gateway --config ~/.nanoinfra-discord/config.json

Each gateway instance also exposes a lightweight HTTP health endpoint on gateway.host:gateway.port. By default, the gateway binds to 127.0.0.1, so the endpoint stays local unless you explicitly set gateway.host to a public or LAN-facing address.

• GET /health returns {"status":"ok"}
• Other paths return 404

Override workspace for one-off runs when needed:

nanoinfra gateway --config ~/.nanoinfra-telegram/config.json --workspace /tmp/nanoinfra-telegram-test

Common Use Cases

• Run separate bots for Telegram, Discord, Slack, and other platforms.
• Keep testing and production instances isolated.
• Use different models or providers for different teams.
• Serve multiple tenants with separate configs and runtime data.

Notes

• Cron jobs live in the active workspace. nanoinfra derives runtime media and state from the config directory.