Deployment Targets
Multi-target deployments
The Release Center deploys any app to your own ssdserver or to popular cloud platforms. Pick the source (where the code comes from), the target (where it goes), and the environment — then review the dialog and confirm.
Deployment sources
| Source | What it deploys | When to use |
|---|---|---|
| Dev server (13.140.162.231) | Working tree on staging — includes uncommitted work | Ship exactly what you tested on staging |
| ssdserver (206.51.227.27) | Current production files | Re-deploy / promote the current prod state to another target |
| Gitea repo (main) | Committed, reviewed code | Auditable releases with full git diff |
The dev source uses a restricted SSH key with a forced command — the Release Center can only fetch whitelisted app directories from dev, never a shell.
Deployment targets
| Target | Best for | Credentials needed | CLI on ssdserver |
|---|---|---|---|
| Self-Hosted (ssdserver) | All current apps — health gate + auto-rollback | none (built in) | — |
| Vercel | Next.js / frontend, edge network, preview URLs | Vercel token + project | npm i -g vercel |
| Amazon AWS | S3 static hosting + CloudFront CDN | Access key + secret, region, bucket | apt install awscli |
| Microsoft Azure | Azure Web App / enterprise | Subscription, resource group, app name | apt install azure-cli |
| Netlify | JAMstack frontend, forms, split tests | Auth token + site ID | npm i -g netlify-cli |
| Cloudflare Pages | Edge deploys on your existing CF account | CF API token + account + project | npm i -g wrangler |
| DigitalOcean | App Platform, managed databases | API token + app ID | snap install doctl |
| Google Cloud Run | Serverless containers, scale-to-zero | Project, service, region, access token | apt install google-cloud-cli |
| Heroku | Classic PaaS, buildpacks | API key + app name | npm i -g heroku |
| Railway | Modern PaaS, usage based | Token + service/project ID | npm i -g @railway/cli |
| Firebase Hosting | Static hosting + Google services | CI token + project ID | npm i -g firebase-tools |
Environments
| Environment | Meaning |
|---|---|
| production | Live traffic (provider production flag, e.g. Vercel --prod) |
| staging | Internal testing — provider preview/alias |
| preview | Preview build for review links |
Connecting a provider (step by step)
- Release Center → Connect a provider
- Pick the provider type + display name
- Paste credentials — tokens are stored root-only on ssdserver, write-only (never re-displayed)
- Click Test — verifies the token and CLI availability
- Use it as a target in the Deploy dialog
Environment variables & secrets vault
Per app, per environment (production / staging / preview). Values are write-only and injected into the deploy process at run time. Use it for API keys, feature flags, provider overrides. Release Center → Environment Variables.
Market-standard features included
- Review-before-deploy dialog (versions, file diffs, source → destination)
- Three deployment sources (dev / ssdserver / Gitea)
- Environments (production / staging / preview)
- Per-release reports (downloadable) + consolidated export across all apps
- Git tags + Gitea Releases per deployment
- Full audit trail (who, when, what, where)
- One-click rollback (self-hosted) / provider history (cloud targets)
- Health gates + automatic rollback on self-hosted deploys
- Write-only secrets vault
Notes & limitations
- Cloud deploys need that provider's CLI installed on ssdserver (see table) plus your account credentials — the Test button tells you exactly what is missing
- Docker-based apps (one, pulsehr, einv, ivyos, primzopms) are built for self-hosted; the Node/SPA apps (lumen, launchpad, ppm, infinity frontends) map cleanly to Vercel/Netlify/Cloudflare
- Cloud rollback uses the provider's own history (Vercel instant rollback, Netlify deploys list, S3 versioning, etc.)
IVY Digital 路 docs.ivydigitals.com 路 generated 2026-10-01 路 Release Center 路 Gitea