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 Authentication

The middleware extracts the JWT from the Authorization: Bearer <token> header, validates it, and attaches the user context to the request. Protected routes use RequireAccess middleware to check user roles.

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

Recordings & LiveKit Egress

Room recording uses a three-layer authorization architecture:

1. Middleware (RecordingsEnabled) — checks system-level SystemSettings.RecordingsEnabled
2. Service (RecordingService) — checks room-level Room.Settings.RecordingsAllowed + LK egress client availability
3. Handler (RecordingHandler) — checks user is room moderator via isRoomModerator()

Recording flow:

• POST /api/rooms/:id/recording/start → moderator check → RecordingService.StartRecording() → LK StartRoomCompositeEgress()
• POST /api/rooms/:id/recording/stop → moderator check → RecordingService.StopRecording() → LK StopEgress() → transition to processing
• A background job (process_recording) downloads the file from LiveKit and stores it
• On completion, recording.completed webhook event is dispatched

Webhooks

Webhook system allows superadmins to register HTTP callbacks for real-time events. Events include room.ended, participant.joined, participant.left, and recording.completed.

• 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