SessionDB Services Overview

This document outlines the core operational components that power SessionDB underneath the configuration layer and how scli routes execution.

The Architecture Stack

SessionDB technically ships as a distributed structure of distinct logical units securely managed under a single install profile.

1. sessiondb-server (Backend Binary)

The core Golang service running the application framework.

• Handles the API schemas and logic outlined in the API Integrations documentation.
• Responsible for parsing environment contexts, decrypting system variables, and orchestrating requests.
• Responsible for JWT lifecycle and serving RBAC rules dynamically against target DB sources.
• Handles serving the static HTML dist/ block generated by the Frontend.

2. Frontend Assets (ui/dist/)

The pre-compiled React 18 frontend interfaces powering the interactive dashboards and administration hubs.

• These static payload blobs are transparently served natively from the /opt/sessiondb/current/frontend node context inside the core backend framework to save execution complexity.
• Directly executes client-side configuration based on dynamic URL patterns (window._env_).

3. The Backend Persistence Services

Depending heavily on configuration via .env files pushed by scli init, SessionDB connects with:

• Relational Metadata Storage: Commonly Postgres. Houses Role settings, audit logs, and operational configuration schemas.
• In-Memory Caching (Redis): Strongly utilized for rapid API schema discovery layer polling, managing concurrent execution queues, and validating high-stress JWT sessions with real-time rate policies.

Secrets Management

Security initialization is critical. scli init automatically performs a zero-knowledge installation and creates these cryptographically safe elements internally avoiding user collision errors:

• DB_CREDENTIAL_ENCRYPTION_KEY: Symmetrically encrypts external DB keys/passwords the user inserts into the platform to maintain secure storage at rest.
• MIGRATE_TOKEN: A secure string token inherently attached to internal migration POST payloads to restrict remote actors from forcing execution schemas on the backend DB.

Tip: Both elements are actively reused without destroying data integrity if config.toml already specifies them actively.

Background Daemon Management

Users have two major pathways for executing the backend logic context based on requirement needs.

Development Loop (On The Fly):

scli run

This spawns the sub-process independently in the immediate bash background, attaching standard Out file tails. The application safely lives on if Ctrl+C terminates the terminal, up until scli stop manually kills the process tree.

Production Loop (Systemd via scli):

scli deploy --platform baremetal --output sessiondb.service

Generates a highly optimized structure systemctl definition relying cleanly on standard hooks:

• Sets working directories directly off current symlinks.
• Dynamically loads standard outputs to unified journals (journalctl -u sessiondb).
• Actively forces required connection mappings towards configuration trees (EnvironmentFile=/path/to/.env).