5. SaaS Kanban

Part 4 gave every user their own boards. A SaaS works differently: a company signs up, its people share data, and nobody outside the company can reach it. Making that change means scoping every query, and a missed filter exposes one customer’s data to another. Read what comes back from this part carefully. feather check helps by failing on a tenant-scoped model queried without a tenant filter, but it checks the query shape rather than your intent.

What you’ll have

Users assigned to a company automatically, by email domain
Boards, columns, cards and attachments isolated per company
A tenant admin who manages users inside their own company
A platform admin who creates companies but doesn’t touch their user lists
Files in cloud storage separated by tenant as well

Which parts of Feather this uses

Multi-tenancy

TenantScopedMixin, get_current_tenant_id() and require_same_tenant().

The two-axis model

Tenant role and platform authority are separate, and admin doesn’t cross companies.

feather check

The tenant-isolation rule turns a missed filter into a failed build.

File storage

Tenant IDs go in the storage path, so buckets are isolated too.

Step 1: Scaffold

Multi-tenancy changes the user model and the admin panel, so start fresh again.

feather new kanban-saas

Prompt	Answer	Why
App type	`multi-tenant`
Database name	`kanban_saas`	Defaults to the project name, and a hyphen in a Postgres database name has to be quoted forever
Redis caching	`n`	Defaults to yes, nothing here uses it
Cloud storage (GCS)	keep the default yes	Attachments need it
Platform admin email	one you can sign in with	`seeds.py` grants it `is_platform_admin`

There’s no database type prompt this time. Multi-tenant apps require PostgreSQL.

cd kanban-saas
source venv/bin/activate

python seeds.py

The first migration is already generated and applied. If Postgres was not running while the app was created, run feather db migrate -m "Initial migration" and feather db upgrade first. The scaffold is meaningfully different from part 4’s:

	Single-tenant	Multi-tenant
User model	no `tenant_id`	has `tenant_id`
Platform admin	no such thing	`is_platform_admin` field
Tenant model	none	full tenant management
Data isolation	per user	per tenant
Admin panel	users	users and tenants

Step 2: Run the prompt

The prompt

I'm working through part 5 of the Feather Kanban tutorial series.

Read the tutorial first:
https://github.com/RolandFlyBoy/Feather/blob/main/tutorials/05-saas-kanban.md

I've scaffolded a fresh multi-tenant app called kanban-saas on
PostgreSQL, with GCS enabled and Redis disabled. Migrations have run and
seeds.py created my platform admin. Google OAuth and GCS credentials are
in .env.

Build the multi-tenant app from Build Steps 1 through 7:

- Kanban using TenantScopedMixin. Column and Card inherit isolation
  through their relationship to the board rather than carrying a
  tenant_id of their own.
- A separate Attachment model, so a card can hold several files.
- The migration. Keep Tenant, User, Log, Account and AccountUser in
  models/__init__.py, and watch the import order, since Alembic creates
  tables in it.
- Tenant-scoped services for board, column, card and attachment.
- Dashboard and board routes, plus the move and attachment API routes.
- Templates, the drag-drop island and a user menu island.
- CSS.

The isolation rules matter more than anything else here:

- Scope every list query with get_current_tenant_id().
- Call require_same_tenant() in the services before acting on anything
  fetched by ID, and let it raise rather than filtering silently.
- Never trust a tenant_id that arrives in a request.
- In move(), check the target column as well as the card. Checking only
  the card lets someone move their own card into another company's
  board.
- Put the tenant ID in the storage path, so the bucket is isolated too.
- Any genuinely cross-tenant route needs @platform_admin_required.

Show me the migration before applying it. Then run `feather check` and
pay attention to the tenant-isolation rule specifically.

Then show me every place a query touches a tenant-scoped model, and tell
me what enforces isolation at each one.

A tenant admin is not a platform admin. An admin at one company must not reach another company’s data, and require_same_tenant() is a hard stop the admin role doesn’t bypass. If the assistant adds an admin shortcut around it, reject the change.

Step 3: Test it

Clicking through your own account proves nothing here. You need two, on different email domains.

feather dev

Create a board, open it, add columns and cards. Then go to Admin, then Tenants.

Create a tenant

Name “Acme Corp”, slug “acme”, domain “acme.com”, set to Active.

They land on the pending approval page.

Promote them to tenant admin

As platform admin: Admin, Tenants, Acme Corp, Users. Set their role to admin and activate them.

Create boards as the Acme user

Then confirm the platform admin’s dashboard doesn’t show them, and the Acme user’s doesn’t show the platform admin’s.

Try to cross the line

Copy a board ID from one account and open /kanban/<that-id> from the other. You want a 403, not a board.

feather check

Zero tenant-isolation errors is the result that matters here.

What the framework did

Isolation is declarative at the model. TenantScopedMixin added tenant_id and the for_tenant() query. Columns and cards don’t carry one, because their owner is reachable through the board, and duplicating it would mean two sources of truth that can disagree. require_same_tenant() raises rather than filters. A filter that silently returns nothing looks identical to a genuinely empty result, which hides the bug. An exception becomes a 403 you can see in the logs. See Multi-tenancy. The linter is the backstop. feather check’s tenant-isolation rule catches a query on a tenant-scoped model with no tenant filter, so the mistake fails CI rather than shipping. See feather check. Approval belongs to the tenant. Platform admins create companies. Each company’s admin approves its own users. That’s what keeps a platform operator out of a customer’s user list, and it’s a product decision the framework encodes rather than leaves to you.

Next: put it on the internet

A VPS, automatic TLS, backups, and a deploy on every push.

Get started

Tutorial: build a Kanban app

Building the UI

Backend

Features

Tooling

Testing

Deployment

What you’ll have

Which parts of Feather this uses

Multi-tenancy

The two-axis model

feather check

File storage

Step 1: Scaffold

Step 2: Run the prompt

Step 3: Test it

What the framework did

Next: put it on the internet

​What you’ll have

​Which parts of Feather this uses

Multi-tenancy

The two-axis model

feather check

File storage

​Step 1: Scaffold

​Step 2: Run the prompt

​Step 3: Test it

​What the framework did

Next: put it on the internet

What you’ll have

Which parts of Feather this uses

Step 1: Scaffold

Step 2: Run the prompt

Step 3: Test it

What the framework did