Multi-Tenant

The Setup Saru has 4 portals: System, Provider, Reseller, Consumer. Each runs on a different subdomain, but they share one Keycloak realm. system.saru.local (port 3001) → Keycloak provider.saru.local (port 3002) → (single realm, reseller.saru.local (port 3003) → 4 clients) consumer.saru.local (port 3004) → Basic Keycloak + Auth.js integration is well-documented in existing tutorials. This article covers the problems those tutorials don’t mention. Pitfall 1: Cookie Collision Across Subdomains The Problem We wanted cross-subdomain session sharing for potential future use, so we set: ...

構成 Saruには4つのポータルがあります：System、Provider、Reseller、Consumer。それぞれ異なるサブドメインで動作しますが、1つのKeycloakレルムを共有しています。 system.saru.local (port 3001) → Keycloak provider.saru.local (port 3002) → (単一レルム、 reseller.saru.local (port 3003) → 4クライアント) consumer.saru.local (port 3004) → 基本的なKeycloak + Auth.js統合については既存のチュートリアルで十分にカバーされています。この記事では、それらのチュートリアルでは触れられない問題を扱います。 落とし穴1: サブドメイン間のCookie競合 問題 将来的な利用を見越して、サブドメイン間でセッションを共有したいと考え、以下のように設定しました： 1 2 3 4 5 6 7 cookies: { sessionToken: { options: { domain: '.saru.local', // サブドメイン間で共有 }, }, } 結果：System PortalにログインするとProvider Portalでも同じセッションが表示されました。しかしそれは間違ったユーザーコンテキストでした。System管理者のトークンがProvider Portalで使用されていたのです。 ...

What You’ll Learn Comparison of data isolation patterns for multi-tenant SaaS Practical usage of PostgreSQL Row-Level Security (RLS) RLS policy design for 4-tier hierarchy (System/Provider/Reseller/Consumer) Setting RLS context with Go + pgx Detecting RLS leaks through testing Introduction As introduced in Part 1, Saru is a multi-tenant SaaS with a 4-tier account structure. System Admin (manages the entire SMS platform) └── Provider (offers services) ├── Reseller (sells services) │ └── Consumer (purchases/manages) └── Consumer (direct sales) In this structure, data isolation is critical. ...

この記事で得られること 「1人で作れる規模」を超えたシステムに挑む際の考え方 複雑なマルチテナントシステムの設計概要 手動テストゼロを実現する自動化戦略 はじめに 「1人で保守できないものは作るな」 ソロ開発の鉄則だと思う。でも、あえてその限界に挑戦してみたくなった。 AIコーディングエージェント（Claude Code、GitHub Copilot等）を数カ月実務で使ってきて、「これなら1人でも複雑なものを作れるかもしれない」と思い始めた。ただし条件がある。徹底的な自動化だ。 このブログでは、マルチテナント型サブスクリプション管理システム「Saru」の開発記録を残していく。複雑なシステムを1人で作り切るために、何を自動化し、どう設計したかを共有する。 なぜ「保守できない複雑さ」に挑むのか AIコーディングエージェントで「ちょっとしたもの」ではなく「本格的なもの」を作ってみたい 1人では普通作れない規模のシステムに、自動化でどこまで対抗できるか試したい 失敗しても学びになる。成功すれば再現可能なノウハウになる Saruの複雑さ 4階層のアカウント構造 一般的なSaaSは「管理者 → ユーザー」の2階層。Saruは4階層ある。 階層 役割 説明 System プラットフォーム管理 全体を統括 Provider サービス提供 SaaSや商品を提供 Reseller 販売代理 Providerのサービスを販売 Consumer 購入・利用 サブスクリプションを購入 さらに： ResellerがPROVIDE権限を持つと独自サービスも提供可能 ConsumerがPROVIDE権限を持つとCreator（個人事業者）になれる この柔軟性が複雑さの源泉であり、差別化ポイントでもある。 4ポータル × 4API 各階層に専用のフロントエンドとAPIがある。 ポータル API ポート System Portal system-api 3001 / 8080 Provider Portal provider-api 3002 / 8081 Reseller Portal reseller-api 3003 / 8082 Customer Portal customer-api 3004 / 8083 ポータルは動的サブドメインで分離（例: provider-xxx.example.com） ...

What You’ll Learn How to approach building systems that exceed “what one person can maintain” Overview of complex multi-tenant system design Automation strategy to achieve zero manual testing Introduction “Don’t build what you can’t maintain alone.” I believe this is a fundamental rule of solo development. But I wanted to challenge that limit. After using AI coding agents (Claude Code, GitHub Copilot, etc.) in production for several months, I started thinking, “Maybe I can build something complex on my own.” But there’s a condition: thorough automation. ...