alexei.dolgolyov 234c3c711e
Build / build (push) Successful in 10m43s
feat(static): inline static-source plugin; drop phantom-row adapter
Lift the static-site deploy pipeline from internal/staticsite/manager.go
into internal/workload/plugin/source/static/ so plugin-native static
workloads operate directly on plugin.Workload + the containers table +
workload_env. The cmd/server/static_backend.go phantom-row adapter is
gone; the legacy static_sites table is no longer touched on plugin
deploys.

Backend
- new state.go: runtimeState (last_commit_sha, last_sync_at,
  last_error, status) persisted in containers.extra_json under the
  deterministic row id <workloadID>:site
- per-workload sync.Mutex serializes saveState read-modify-write so
  parallel deploys for the same workload can't race container_id /
  proxy_route_id writes
- extra_json round-trips through map[string]json.RawMessage so
  unknown keys survive — typed runtimeStateKeys are stripped before
  merge so clearing a typed field actually drops the key
- new env.go reads workload_env (replaces static_site_secrets for
  plugin-native sites); decrypt-failure logs and skips one entry
  rather than failing the whole deploy
- new build.go ports prepareDenoBuild + prepareStaticBuild + copyDir;
  copyDir uses filepath.WalkDir + Lstat to refuse symlinks and
  non-regular files
- new deploy.go is the ~300-line core; intent.Reason gates force vs
  skip-if-no-changes; success-path saveState failure rolls back
  container + proxy route and writes "failed" state (no orphans)
- new teardown.go combines Remove + Stop; idempotent on
  never-deployed workloads
- new reconcile.go refreshes container state from Docker; flips
  runtimeState.Status to failed when the container is missing/crashed

Hardening (from go-reviewer + security-reviewer subagent passes;
1 CRITICAL + 5 HIGH + 3 MEDIUM addressed before merge)
- path-traversal defense in all 3 providers (gitea_content,
  github_provider, gitlab_provider): reject tree entries whose
  resolved local path escapes destDir
- verifyDownloadInsideRoot walks the build dir post-download as a
  second line of defense
- sanitizeError redacts the access token, collapses to one line, and
  clamps to 240 bytes before persisting to extra_json or fanning out
  to the notification webhook
- container/image/volume names suffixed with workload-id short prefix
  (workload name is not UNIQUE in schema)
- primaryDomain reads settings.Domain to complete a bare subdomain
  face into a full FQDN (matches legacy Manager behavior)
- ctx-aware health-check sleep
- json.Marshal for event metadata (was fmt.Sprintf JSON template)
- strings.HasPrefix for failed-status detection (was brittle slice
  expression)

Wire-up
- cmd/server/main.go: removed wireStaticBackend(...) call; existing
  blank import on _ ".../source/static" drives init() registration
- cmd/server/static_backend.go deleted

Doc
- WORKLOAD_REFACTOR_TODO: static port marked DONE; next focus is
  the hard legacy cutover (drop /api/projects, /api/stacks,
  /api/sites, /api/stages + their tables, internal/stack +
  internal/staticsite packages, frontend /projects /stacks /sites)

Behavior notes for operators
- plugin-native static workloads no longer write to static_sites;
  legacy /api/sites/* still serves original rows unchanged
- legacy tinyforge.static-site / .static-site-name container labels
  dropped on plugin deploys; canonical tinyforge.workload.id / .kind
  cover ownership
- container/image/volume names gained an 8-char ID suffix
  (e.g. dw-site-mysite-a1b2c3d4); legacy-deployed sites keep the
  old shape until redeployed through the plugin path
2026-05-16 02:56:23 +03:00

Tinyforge

Self-hosted deployment platform with a web dashboard. Deploy Docker containers from registries with zero-downtime blue-green strategy, host static sites and Deno APIs directly from Git repositories, and manage reverse proxy configuration — all from a single binary.

Features

Container Deployments

  • Registry polling and webhook receiver for automatic deployments
  • Blue-green deploys with health checks and automatic rollback
  • Multi-stage projects (dev, staging, prod) with tag pattern matching
  • Real-time deploy logs via SSE streaming

Static Sites

Deploy static sites and Deno-powered APIs directly from Git repositories:

  • Git providers: Gitea/Forgejo, GitHub, and GitLab (public and private repos)
  • Static mode: Serves HTML/CSS/JS via nginx container
  • Deno mode: Full-stack with TypeScript API backend + static frontend — API routes are auto-discovered from /api folder using a naming convention (API_get_users, API_post_items, etc.)
  • Markdown rendering: Optionally converts .md files to styled HTML
  • Branch & folder picker: Select any branch and subfolder as the deployment root
  • Auto-sync: Trigger redeployment on push or tag events, or manually
  • Per-site secrets: Encrypted environment variables injected at runtime

Infrastructure

  • NPM / Traefik integration for automatic reverse proxy and SSL configuration
  • Cloudflare DNS sync for automatic DNS record management
  • Volume management: Create, browse, upload, and download Docker volumes
  • Stale container cleanup: Detect and remove unused containers
  • Image management: List and prune unused Docker images
  • Database backups: Scheduled and manual backups with one-click restore
  • Config export/import: YAML-based seed configuration for reproducible setups

Auth & Security

  • Local auth with bcrypt password hashing
  • OIDC/SSO support for single sign-on
  • Encrypted credential storage (AES-256-GCM)
  • Role-based access: Admin and user roles

Prerequisites

  • Docker with Docker Compose
  • A Docker network for deployed containers (e.g. staging-net)
  • Nginx Proxy Manager (optional, for automatic proxy configuration)
  • Wildcard DNS pointing to your server (for subdomain-based routing)

Quick Start

  1. Create the Docker network (containers will be attached to this):

    docker network create staging-net
    
  2. Create a .env file (see .env.example):

    cp .env.example .env
    # Edit .env and set ENCRYPTION_KEY and ADMIN_PASSWORD
    # Generate a key: openssl rand -hex 32
    
  3. Start Tinyforge:

    docker compose up -d
    
  4. Open the dashboard at http://localhost:8080 and log in with admin / your ADMIN_PASSWORD.

Configuration

Environment Variables

Variable Required Description
ENCRYPTION_KEY Yes AES-256 key for encrypting stored credentials. Use openssl rand -hex 32
ADMIN_PASSWORD Yes (first launch) Password for the default admin user
SEED_FILE No Path to YAML seed config (default: ./tinyforge.yaml)
DATA_DIR No SQLite database directory (default: ./data)
LISTEN_ADDR No HTTP listen address (default: :8080)
NPM_URL No Override NPM API URL (otherwise uses value from settings)
POLLING_INTERVAL No Registry polling interval, Go duration string e.g. 5m (default from settings)

Seed Config

On first launch, Tinyforge imports a YAML seed file to pre-configure registries, projects, and settings. See tinyforge.example.yaml for the full format.

Webhook Integration

After setup, find your webhook URL at Settings > Webhook URL in the dashboard. Configure your CI/CD (Gitea Actions, GitHub Actions) to POST to this URL on image push:

curl -X POST https://your-domain/api/webhook/<secret> \
  -H "Content-Type: application/json" \
  -d '{"image": "registry.example.com/org/app:v1.2.3"}'

OIDC Setup

  1. Go to Settings > Auth in the dashboard
  2. Switch auth mode to OIDC
  3. Enter your provider's Issuer URL, Client ID, and Client Secret
  4. Set the Redirect URL to https://your-domain/api/auth/oidc/callback

Development

# Build frontend
cd web && npm install && npm run build && cd ..

# Run backend (requires ENCRYPTION_KEY and ADMIN_PASSWORD env vars)
go run ./cmd/server

# Or use Make
make build
make dev

Architecture

CI/Registry --> Webhook/Poller --> Deployer --> Docker + NPM
                                      |
Git Repo ----> Static Sites -------> Docker + NPM
                                      |
                                  Event Bus --> SSE --> Web Dashboard
  • Backend: Go 1.24, chi router, SQLite (pure Go), Docker SDK
  • Frontend: SvelteKit 2, Tailwind CSS 4, TypeScript
  • Deployment: Single binary with embedded SPA, multi-stage Dockerfile
S
Description
No description provided
Readme 66 MiB
Languages
Go 56.7%
Svelte 37%
TypeScript 5.1%
CSS 1%