← Start Here

START HERE FEATURE

Base Tenant

The first tenant is configuration, not ceremony: define it in `.env`, register the host, restart, and open the tenant like a real product surface.

Feature Guide

A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.

What this does

Establish one default tenant context early so tenant-aware behavior is visible before the rest of the application grows.

Tenant Bootstrap

Add the first tenant to `.env` and open it through a real host

There is no separate bootstrap wizard required for the normal local flow. Define the tenant in environment variables, register the host, restart, and open it in the browser.

Step 1

Declare the tenant in `.env`

Use one tenant id prefix and keep the first tenant shape explicit.

TENANCY_BASE_DOMAIN=semitexa.test
TENANT_ACME_NAME=Acme Workspace
TENANT_ACME_STATUS=active
TENANT_ACME_DOMAIN=acme.semitexa.test

Step 2

Register the tenant host

The domain must exist in the local DNS helper as well as in the tenancy configuration.

bin/semitexa local-domain:add acme.semitexa.test
bin/semitexa server:restart

Step 3

Open the tenant

Browse the tenant host directly so resolution happens through the real request host.

http://acme.semitexa.test

Useful Variants

  • Use `TENANT_<ID>_DOMAINS` when the same tenant should answer to more than one local host.
  • Use `TENANT_<ID>_PUBLIC_DOMAIN` and `TENANT_<ID>_PUBLIC_DOMAINS` when you separately model public production hosts.
  • The tenant id is the part between `TENANT_` and the field suffix. `TENANT_ACME_*` becomes tenant id `acme`.
tenant tenant context tenant config default tenant

Verified against Semitexa Ultimate 2026.09.19.1020

Base Tenant

Introduce tenancy with one stable base tenant before expanding into multi-tenant complexity.

Canonical flow

  1. Define the default tenant identity.
  2. Make sure the runtime resolves one known tenant cleanly.
  3. Verify the tenant context affects branding, locale, and feature decisions consistently.

What this proves

  • tenancy is an explicit runtime boundary
  • tenant resolution is not hidden inside controllers
  • later tenant-specific behavior grows from a clear starting point

Why this matters

If the first tenant boundary is vague, the rest of the system will treat tenancy as a scattered conditional instead of a real architectural concept.

Resolution Rules

What makes the first tenant reliable

A tenant should be easy to explain from configuration alone. If it takes custom lore to know which host resolves to which tenant, the local setup is already too fragile.

Keep tenant ids stable and human-readable because they become part of local and operational reasoning.

Prefer one clear primary `TENANT_<ID>_DOMAIN` before introducing additional aliases.

When tenant resolution looks wrong, check `.env`, then `local-domain:list`, then the actual browser host in that order.

Use the Tenancy pages after this setup if you want to inspect how Semitexa resolves and propagates tenant context internally.

Support Semitexa
Built for developers who prefer control over magic. Your support helps keep it fast, open, and evolving.

Donate via PayPal