Productify

Appearance

Deployment Overview ​

Running the Productify platform yourself: which components exist, which deployment platform to pick, and where the detailed guides are. Start here if you are about to install or operate Productify.

Early Development

Productify Framework is in active development. The deployment guides are functional, but expect breaking changes, and have backup and rollback strategies in place before deploying to production.

Components ​

The Productify Framework consists of three main components:

Manager ​

Core management platform for multi-tenant SaaS:

  • Backend: Go-based API server with GraphQL
  • Frontend: Vue.js 3 UI
  • Database: PostgreSQL
  • Run Modes: API, Executor, or Both

Manager Deployment Guide

Autoscaler ​

Predictive scaling:

  • Nomadscaler Plugin: Go-based Nomad Autoscaler strategy plugin (productify-scaler)
  • Optimizer Service: Python-based MILP optimizer
  • Metrics Integration: Nomad APM, Prometheus

Autoscaler Deployment Guide

Proxy ​

The single entry point in front of everything:

  • Caddy custom build: TLS (Let's Encrypt or internal CA), HTTP/2
  • Login: OAuth2/OIDC through Pocket ID (caddy-security), tenant selection, identity-header injection
  • Configuration: the Manager renders per-application vhosts and pushes them through Caddy's admin API

Proxy Deployment Guide

Architecture Overview ​

For detailed system architecture, network topology, and deployment models, see the Architecture Guide.

Launch Criteria ​

The framework's "Early Development" warnings and the website "early access" badge are dropped only once the exit criteria are all met. The criteria are a checklist a reviewer works through before the flip; no CI check enforces them. See Launch Criteria for the criteria and how each one is checked.

Generated Deployment Artifacts ​

Deployment artifacts render from specs; you maintain inputs, not HCL or Caddyfiles. See Generated Artifacts for the full workflow.

  • Application jobs: each application's Nomad job (ports, health checks, migration prestart, secrets templates, scaling policy) renders from a deployment spec stored on the Manager's Deployment entity: pfy nomad render|deploy.
  • Platform stack: Manager, proxy, identity provider, and database jobs (or the Compose equivalent) render from one install.yaml: pfy platform render|deploy.
  • Proxy configuration: per-application vhosts render from Manager data and push live through Caddy's admin API; the install-level prelude (OAuth portal, global options) renders from install.yaml.
  • Drift detection: rendered files carry a GENERATED header with the spec hash; pfy deploy diff compares spec vs. repo vs. cluster, and CI fails on hand-edited drift (pfy proxy diff|sync for the proxy).

Rendered outputs are committed, deterministic, and never contain secrets (they reference Nomad variables / environment instead).

Deployment Platforms ​

Docker Compose (single node) ​

The versioned install bundle (deployments/compose) runs the whole platform on one machine with pinned images and one .env. It is the supported self-hosted install and the fastest way to evaluate the platform. See Docker Compose Deployment.

Nomad (scale-up) ​

The same pinned versions, rendered as Nomad jobs from one install.yaml (pfy platform render|deploy), with horizontal scaling of the Manager API and the autoscaler for applications. See Nomad Deployment.

For day-to-day development neither is needed: pfy dev up starts a local stack. See the Zero-to-App Local Quickstart.

Manager Run Modes ​

The Manager can run in three modes:

  • both: one process running API + Executor (development, or the smallest installs)
  • api: horizontally scalable API instances
  • executor: the single instance that runs triggers and every background sweep

For detailed configuration, see Manager Deployment.

Deployment Strategies ​

For deployment patterns including blue-green, canary, and rolling updates, see the Architecture Guide - Deployment Strategies.

High Availability ​

For high availability setup including database replication, application redundancy, and proxy HA, see the Architecture Guide - High Availability.

Monitoring & Observability ​

For monitoring setup including metrics collection, centralized logging, health checks, and alerting, see the Architecture Guide - Monitoring.

Centralized logging ships as ready-to-run configuration (Loki + Promtail) for both the Compose and Nomad paths under deployments/ops/logging/. See Architecture Guide - Logging.

Security ​

For security practices including network security, secrets management, and access control, see the Architecture Guide - Security.

Operations ​

For incident response, keyed to the shipped alert rules and log/backup tooling, see the Incident Runbook. For severities, escalation, and where alerts land, see the On-Call Guide.

Backup & Recovery ​

For backup strategies, disaster recovery planning, and RTO/RPO guidelines, see the Architecture Guide - Disaster Recovery.

Next Steps ​

  1. Review the architecture
  2. Install with the Compose bundle, or render the Nomad stack from install.yaml
  3. Read the Configuration Reference and its minimum secure production checklist
  4. Set up monitoring and read the runbook