The Bedrud server is a Go application that provides the REST API, serves the embedded web frontend, and manages the LiveKit media server.

Technology Stack

Directory Structure

server/
├── cmd/
│   ├── server/main.go        # Development entry point
│   └── bedrud/main.go        # Production entry point (with install/livekit flags)
├── internal/
│   ├── auth/                  # Authentication services
│   │   ├── auth.go            # Core auth service (register, login, OAuth)
│   │   ├── jwt.go             # JWT token creation and validation
│   │   └── session_store.go   # Gorilla session store for OAuth state
│   ├── database/              # Database initialization and migrations
│   ├── handlers/              # HTTP request handlers (controller layer)
│   │   ├── auth_handler.go    # Auth endpoints
│   │   ├── recording_handler.go # Recording start/stop/list/get
│   │   ├── room.go            # Room endpoints
│   │   └── users.go           # User management endpoints
│   ├── middleware/             # Fiber middleware
│   │   ├── auth.go            # JWT validation, permission checks
│   │   └── recordings_enabled.go # Recordings sys-setting gate
│   ├── models/                # GORM models (database schemas)
│   │   ├── user.go            # User model
│   │   ├── webhook.go         # Webhook model
│   │   ├── recording.go       # Recording model
│   │   ├── room.go            # Room model
│   │   └── passkey.go         # Passkey model
│   ├── repository/            # Data access layer (SQL via GORM)
│   │   ├── user_repository.go
│   │   ├── webhook_repository.go
│   │   ├── recording_repository.go
│   │   ├── room_repository.go
│   │   └── passkey_repository.go
│   ├── services/               # Business logic layer
│   │   ├── recording_service.go # Recording gate chain + LK egress
│   │   └── room_cleanup.go     # Room deletion/suspend cascade
│   ├── livekit/               # Embedded LiveKit server management
│   ├── scheduler/             # Background job scheduling
│   └── utils/                 # TLS and other utilities
├── frontend/                  # Embedded web frontend (populated at build time)
├── config.yaml                # Development configuration
├── livekit.yaml               # Development LiveKit configuration
├── go.mod
└── go.sum

Layered Architecture

The server follows a layered architecture:

flowchart TB
    HTTP[HTTP Request] */} Middleware
    Middleware["Middleware<br/>JWT validation, CORS, logging"] */} Handlers
    Handlers["Handlers<br/>Parse requests, call services, format responses"] */} Services
    Services["Services<br/>Business logic (auth, room management)"] */} Repository
    Repository["Repository<br/>Database queries via GORM"] */} Database
    Database["Database<br/>SQLite (dev) or PostgreSQL (production)"]

Key Patterns

Embedded Frontend

The web frontend is compiled to static files and embedded into the Go binary using //go:embed:

//go:embed frontend/*
var frontendFS embed.FS

At build time, bun run build:embed SSR pre-renders the React app and copies dist/client/ into server/frontend/. The Go compiler then bundles it into the binary. The Fiber server serves these files for any non-API route.

JWT 認証

ミドルウェアは Authorization: Bearer <token> ヘッダーから JWT を取り出し（読み取り時は Cookie フォールバック可）、検証してユーザー文脈をリクエストに付与します。保護ルートは RequireAccess でロールを確認します。

• 用途トークン（email_verify、password_reset）は署名鍵を共有しますが、Protected ルートのアクセストークンとしては使えません。
• 変更系（認証付き POST/PUT/PATCH/DELETE）は RequireBearerForMutations による Bearer が必須 — Cookie のみのクロスサイト POST は拒否（CSRF 対策）。
• アクセストークン失効（ログアウト / パスワード変更）は DB に永続化され、再起動やマルチインスタンスでも有効です。
• ルーム在席の ID 一覧には認証が必要。公開ルームは ?countOnly=1（人数のみ、ID なし）を公開できます。

LiveKit Token Generation

When a user joins a room, the server:

1. Validates room permissions
2. Creates a LiveKit access token signed with the API secret
3. Returns the token to the client
4. The client connects directly to LiveKit using the token

録画と LiveKit Egress

キューハンドラ process_recording と recording_delete はワーカーに登録済みです。LiveKit の egress_ended Webhook は process_recording をエンキューします（ダウンロード → 保存 → 完了マーク → 任意の recording.completed Webhook）。

🚧 HTTP 録画ルート（API の start/stop/list）は本番ルート表で // TODO oncoming feature のままです — 公開されるまで公開録画 REST に依存しないでください。recording: 配下の YAML がパイプラインの保存先を設定します。

Webhooks

Webhook system allows superadmins to register HTTP callbacks for real-time events. Active events: room.created, room.ended, participant.joined, and ping (test). recording.completed is reserved for a planned feature. Delivery headers: X-Bedrud-Signature, X-Bedrud-Event, X-Bedrud-Timestamp.

• Storage: Webhook model in database, CRUD via WebhookRepository
• Dispatch: Background job (dispatch_webhook) sends HMAC-SHA256 signed POST requests with 10s timeout
• Secrets: Per-webhook HMAC secret, rotatable via admin panel
• See the Webhooks API for endpoint details.

Swagger Documentation

API documentation is auto-generated from code annotations using swaggo. In development, it’s available at /api/swagger/.

Database

SQLite (Default)

For development and small deployments, Bedrud uses SQLite. The database file is stored at the configured database.path (default: data.db).

PostgreSQL

For production with higher concurrency requirements, configure a PostgreSQL connection string. GORM handles both dialects transparently.

Migrations

GORM auto-migrates the schema on startup based on the model structs. The models are defined in internal/models/.

Background Jobs

The gocron scheduler runs periodic tasks such as:

• Cleaning up expired refresh tokens
• Removing stale room participants

See also

• Backend Code Structure - directory map and coding standards
• API Handlers - routing and request lifecycle
• Database and Models - GORM models and repository pattern
• Authentication Flow - JWT, OAuth, and passkey internals