Changelog
Every release across the platform, API and dashboard — features, fixes and improvements as they ship.
sleep namespace)./dashboard/projects/:id/shell page (xterm.js, same terminal chrome as the server terminal) attaching an interactive shell inside the project's container over the runner-aware SSH path; opens via the Shell button in the Logs tab. ServerTerminalView now accepts projectId for the app-shell socket alongside serverId.sleepAfterMinutes (default 30, 5–1440) with no meaningful traffic — judged from the container's rx/tx counters in container_metrics, with a 500KB window threshold that swallows health-check chatter and a post-deploy/wake grace period — a 5-minute sweeper stops the container (SSH on server/runner, local fallback) and marks the project sleeping. Wake on request: generated nginx vhosts now include an error_page 502 = @pushify_wake fallback proxying to the new public /api/v1/wake/:slug endpoint, which CAS-claims the wake (exactly one starter under concurrent visitors), docker starts the container, and serves an auto-refreshing "Waking up…" page — genuine crashes get a branded unavailable page instead of a raw nginx 502 (fallback emitted only when API_BASE_URL is set). Also: authenticated POST /projects/:id/wake for the dashboard, health checks skip sleeping/waking apps (auto-restart would fight the sweeper), a deploy resets sleep state, and disabling auto-sleep while asleep starts the container back up. Migration 0033 adds the projects columns./ws/projects/:projectId/shell (same message protocol as the server terminal): SSHes to the server the container actually runs on — the project's assigned server or its sticky runner — resolves the blue/green container on the host and attaches an interactive docker exec (bash when the image has it, sh otherwise) over a real PTY. SSHShellSession gained an exec-with-PTY mode alongside the login shell. Owner/admin only, slug validated before command interpolation, shares the 50-session cap.logs namespace).volumes namespace).cron namespace).GET /projects/:id/logs/search?q=&logType=&limit=) for the dashboard's new Logs explorer: searches the persisted 7-day container_logs chunks (ILIKE with escaped wildcards, literal substring semantics), extracts matching lines with their chunk timestamp / stdout-stderr type / deployment id. Bounded: max 100 chunks scanned, max 1000 lines returned.pushify-vol-<slug>-<name>) at a chosen container path — SQLite files, uploads, caches survive every redeploy. Mounts are applied on all container start paths: standard remote deploy (blue-green), quick rollback, and local. New project_volumes table (migration 0032), REST CRUD (/projects/:id/volumes), validation (shell-safe names, absolute paths, /proc,/sys,/dev,/etc… mount targets denied), max 5 volumes/project. Changes take effect on the next deploy; project teardown removes the project's pushify-vol-* volumes.completeBlueGreenSwitch recreates the new container from docker inspect (image + env) but never carried over mounts — any volume (marketplace or user) would silently detach at the switch. The recreate now reads the container's volume/bind mounts and re-applies them.docker exec over SSH on the project's server or runner, timeout-guarded, local fallback), and http — a GET to a URL (SSRF-guarded, timeout-bounded). Standard 5-field cron expressions with an IANA timezone per task (croner). New tables scheduled_tasks + scheduled_task_runs (migration 0031): precomputed next_run_at claimed atomically (CAS) by a 30s worker tick so each firing runs exactly once even with multiple workers; run history keeps exit code / HTTP status / captured output (8KB cap) for 7 days. REST: list/create/update/delete, Run now (POST .../run, synchronous, recorded as trigger=manual), and run history. Caps: 10 tasks per project, 10–600s timeout. Full migration chain re-verified on a fresh Postgres 16.CHANGELOG.md (local checkout first, GitHub raw as fallback once the repos are public), ISR-refreshed hourly so new releases appear without a redeploy. Footer link now points here instead of GitHub; added to the sitemap./env/clone endpoint that previously had no UI.metrics:update and healthcheck:result WebSocket events (hooks existed but were never mounted): charts and health logs refresh on push instead of waiting for the 15–30s polling intervals; time-series chart invalidation added for every hours-window.Dockerfile producing a Next.js standalone build (enabled output: 'standalone' in next.config.ts — no effect on next dev). The backend's selfhost/docker-compose.yml + install.sh use it to run the dashboard as part of the one-command self-host stack. Note: NEXT_PUBLIC_API_URL is inlined at build time, so it's a build arg — changing the API URL requires rebuilding the image.discord channel type alongside slack/email/webhook: paste a Discord incoming-webhook URL and deployment/health events arrive as rich embeds (event color, project/branch/commit/status fields, log tail on failures, link back to the dashboard). Implemented on both delivery paths (direct send in notification.service with the SSRF guard, and the BullMQ notification.worker). Migration 0030 adds the enum value. Note: the auto-generated migration was hand-trimmed to just the enum change — the schema had drifted from the migrations dir (earlier releases used db:push), and the generated file would have re-added already-existing columns and broken fresh installs; the new 0029_snapshot.json now captures the full current schema so future generates diff cleanly. Full migration chain verified against a fresh Postgres 16.redis-connection.test.ts — BullMQ must honor the DB index in REDIS_URL (staging/prod queue collision); runner-routing.test.ts — sticky runner-pool assignment, legacy env fallback, and resolveProjectServerId preferring the assigned server (the "Container is not running" log-stream bug); effective-plan-limits.test.ts — planLimitsOverride must reach effective limits without mutating shared plan definitions (the grant-org / disabled Create Server bug); utils.test.ts — normalizeClientIp first-IP + varchar(45) cap (the login 500 from long x-forwarded-for chains).curl -fsSL .../selfhost/install.sh | bash now stands up the entire platform on any Docker host: it clones backend + frontend, generates secrets (JWT_SECRET, ENCRYPTION_KEY, DB password), and starts a full stack — dashboard, API, worker, one-shot migrator, Postgres 16, Redis 7 — via selfhost/docker-compose.yml. New multi-stage Dockerfile builds a single backend image used for the API (dist/index.js), the worker (dist/worker.js) and migrations. New src/migrate.ts (built to dist/migrate.js, npm run db:migrate:prod) applies Drizzle SQL migrations programmatically so production doesn't need drizzle-kit/dev deps. Full guide in docs/SELF_HOSTING.md — including the deploy model: the containerized control plane has no host Docker/nginx access by design; apps deploy to servers attached over SSH (which can be the same machine), exactly like Pushify Cloud.pushify-dev/pushify-frontend → pushifydev/pushify_frontend).project.serverId, so a free/unassigned project — which has no serverId but still deploys to a runner via sticky routing — was treated as local, looked at the control-plane's Docker, found nothing, and returned *"Container is not running."* Extracted the deploy-target resolution into lib/runner-routing.ts (pickRunnerServerId + resolveProjectServerId = project.serverId || runner) — the same logic the deploy worker uses — and the log stream now SSHes into the actual runner. (Other serverId-gated container ops, e.g. custom-domain nginx in domain.service, should adopt resolveProjectServerId too as runner usage grows.)redis://host:6379/1 → db 1). The queue connection previously parsed only host/port/auth and silently dropped the db, so every environment sharing a Redis host landed on db 0 with the same static queue names (deployments, notifications, …). On a box running both staging and production, that meant a staging worker could pick up and run a production deployment job (and vice-versa) — which also silently broke runner routing: the staging process lacks PUSHIFY_RUNNER_SERVER_IDS, so it fell back to a local deploy and failed with *"Docker is not available on this machine."* Centralized the connection parsing (lib/redis-connection.ts) across the enqueue side and all queue workers (deployments, notifications). To isolate environments sharing one Redis, point each at a different db — e.g. production …/0, staging …/1.apiRequestsPerMinute was meant for *programmatic* API keys, not the browser. Authenticated session (JWT) traffic now uses a separate, generous per-org limit (RATE_LIMIT_SESSION_MAX, default 600/min) that only guards against a runaway client loop; API keys keep their per-plan limit unchanged. This removes the constant 429s while managing a project (especially during a deploy) without weakening API-key tiering or anonymous/IP flood protection..env so IP-based limiters (login/refresh) use the real client IP instead of bucketing every user under the proxy's address.\n juggling needed. In the inline editor, plain Enter inserts a newline and Cmd/Ctrl+Enter saves (Esc cancels). The .env bulk-paste parser is unchanged.useUpdateEnvVar hook / backend PATCH /:envVarId — the value is updated and applied on the next deploy. (Renaming a key is still delete + add.)npm run grant-org): set an organization's plan and/or planLimitsOverride directly, without Stripe — for the operator's own org (e.g. --servers 1 to add the platform runner) or to comp a partner. Uses the existing per-org planLimitsOverride (merged on top of plan limits by getEffectivePlanLimits), so the org keeps its real billing state but gains the granted capacity. Examples: grant-org -- --org <id> --servers 1, --plan hobby, --override '{"servers":2,"projects":20}'.PUSHIFY_RUNNER_SERVER_IDS (comma-separated servers row ids) defines a pool of dedicated runner hosts that free/unassigned deploys land on; a project is stickily and deterministically mapped to one runner by its id, so its redeploys always go to the same host (its subdomain/state stay put) while projects spread across the pool. Scales to N runners by just adding ids — no code change. The single PUSHIFY_RUNNER_SERVER_ID from beta.33 is still honored as a one-runner pool. (Note: actually serving 2+ runners also needs per-app DNS so <app>.pushify.dev resolves to that app's runner — a wildcard A record only points at one host; that piece comes when the 2nd runner is added.)PUSHIFY_RUNNER_SERVER_ID env (a servers row id): when a project has no user-assigned serverId, the deploy now lands on that runner over SSH (same remote path as a user's own server) — keeping untrusted free-tier workloads off the box that runs pushify.dev + the API + the platform database. If unset, behavior is unchanged (deploys fall back to the local host). The deploy-target resolution (deployTargetServerId = project.serverId || PUSHIFY_RUNNER_SERVER_ID) is applied across the standard, static-site, blue-green and quick-rollback paths; per-project server assignment, cleanup and GC still key off the user's real serverId.resolveProjectPort now uses the actual host port recorded on the most recent deployment as the source of truth (every deploy path — blue-green, marketplace, quick-rollback — records the real port it published on), falling back to the PORT env and then the assigned port only if no deployment port is available. This also covers the edge case of a marketplace app with a manually-set PORT plus a custom domain.PORT env value when set (e.g. 1367), but the domain → Nginx setup derived the proxy target from the *assigned* port (getOrAssignPort) instead, so the vhost proxied to the wrong port and returned 502 even though the app was reachable on its real port. Domain verification and the apply-settings path now resolve the app's actual published port the same way the deploy does (PORT env first, assigned port as fallback) via a shared resolveProjectPort helper.pushify-db-<name>) runs on the default bridge network, where Docker provides no name resolution — so a deployed app connecting to pushify-db-<name> failed with ENOTFOUND, and there was no reliable host to use instead. Every remote deploy (standard, blue-green, and quick-rollback) now joins the app and all pushify-db-* containers to a shared pushify Docker network, so the app reaches its database by container name with no host/IP guessing. Scoped to servers that actually have Pushify databases (i.e. the user's own server) — the shared host is unaffected. The database's public-port choice is untouched (still the user's decision); this only adds private app↔database connectivity.gcOrphanedLocalDeployments, every 30 min from the background workers) tears down any local pushify-<slug> deployment whose project no longer belongs there — safe by construction: it only acts on projects that have a remote serverId (so they must not have a local deployment) or are deleted, matched by exact name. Also runnable on demand with npm run gc:orphans.buildRemoteTeardownScript, used by project delete, server-move cleanup, and the new GC) now also removes the project's built images (pushify/<slug>*), not just the containers/vhost/dir — so cleanups actually reclaim the disk that images consume.*.pushify.dev subdomain.** A *.pushify.dev auto-subdomain only works on Pushify's shared host (where the wildcard cert lives and the *.pushify.dev DNS points). When a project that was created on the shared host got moved to the user's own server, the deploy still tried to configure that same subdomain on the user's server — which failed (nginx -t: wildcard cert not present) and was conceptually wrong (the subdomain resolves to Pushify's host, not the user's server). Both remote-deploy paths (standard + blue-green) now check whether the target server actually has the wildcard cert; if a carried-over auto-subdomain isn't usable there, the auto-generated domain record is removed and the project is served over the server's IP (http://<ip>:<port>) instead. A user's own server only gets a public domain when they add their own (which then gets a real per-domain Let's Encrypt cert).serverId — the old container/images kept running on the previous host (e.g. the shared Pushify server), wasting resources and potentially still answering on the old subdomain. updateProject now detects a server change and runs the existing best-effort cleanup (cleanupProjectContainers) against the previous host (using the pre-update snapshot) so the old deployment is removed; the next deploy lands on the new server. (Reminder: assigning a server still requires it to be running + setup completed, otherwise the assignment is rejected and the project stays where it is.)*.pushify.dev vhost hardcoded its certificate path from PREVIEW_BASE_URL (/etc/letsencrypt/live/<base>/), ignoring WILDCARD_SSL_PATH. When the wildcard cert lives under a different lineage name (e.g. the apex pushify.dev cert already owns /etc/letsencrypt/live/pushify.dev, so the wildcard is at .../pushify.dev-0001), Nginx looked for a cert that wasn't there → cannot load certificate ... No such file → nginx -t failed → the config was never applied. generateAutoSubdomainSiteConfig now uses WILDCARD_SSL_PATH when set (falling back to the base-domain path), matching the deploy workers' existing resolution. Set WILDCARD_SSL_PATH to the wildcard's live dir.value too long for type character varying(45)). The client IP was taken straight from the x-forwarded-for header and written to the ip_address varchar(45) column — but behind multiple proxies (nginx/Cloudflare) that header is a comma-separated list of IPs that overflows 45 chars, which threw on session creation and broke every login (password + Google/GitHub OAuth). Added a shared normalizeClientIp() that keeps only the first (client) IP and caps it to 45 chars, applied at session creation and activity logging. Not data/Postgres related — purely the header length.running but whose setupStatus is still pending/installing (e.g. the one-shot server-setup poll job died on a worker restart, even though the server's /health is up), the sweep re-checks http://<ip>/health every 30s and marks the server completed (sending the server-ready email) once it responds — or failed only after a generous 30-minute deadline. This closes the same silent-stuck gap on the setup stage that beta.23 closed on provisioning. npm run requeue:stuck-servers (which runs the sweep) recovers any already-stuck servers immediately.server-status poll job only retries for ~5 minutes; if the VM reaches running on the provider later than that (slow boot, or the worker process restarted mid-poll), the job exhausted and gave up silently — leaving the server stuck at provisioning even though the VM was actually running. Added an independent provisioning reconciliation sweep (reconcileProvisioningServers, runs every 30s from the background workers) that re-checks every server still stuck at provisioning and drives it forward: promotes it to running and hands off to setup as soon as the provider reports it ready (idempotent — the fixed setup jobId de-dupes), or marks it error with a clear retryable message if the provider errored or it's been provisioning past a 20-minute deadline (no more silent dead-ends). The existing poll/setup workers are unchanged — this is a safety net.scripts/requeue-stuck-servers.ts (npm run requeue:stuck-servers) to immediately recover any servers already stuck at provisioning (or running with setup still pending).ceil(bytes / GB) >= limit, so a free org (1 GB) was blocked the moment *any* storage was recorded. It now compares real bytes against limit × GB. - Per-deploy cumulative inflation. Each deploy added its image size to a running "peak" that never decreased (even though only the last 5 images are kept on disk), so redeploys eventually tripped the limit. Storage is no longer metered by cumulative deploy size. - Whole-host over-counting on shared hosts. Storage was measured as the entire host's docker disk and attributed to *every* org on it. It's now measured per-org as the footprint of that org's own project images (pushify/<slug>), so co-tenants aren't charged for each other's images or for build cache.scripts/reset-storage-usage.ts (npm run reset:storage-usage [-- --org <id>]) to clear the previously-inflated current-period peaks; the next disk sync re-records the correct per-org footprint.requiresTwoFactor challenge (for an account with 2FA enabled), the callback stores the challenge token and hands off to the existing 2FA form on /login instead of trying to read tokens that aren't there — so OAuth sign-in goes through the same second-factor step as password login. (Pairs with backend 0.2.0-beta.21.)twoFactorEnabled flag — so a user who had enabled 2FA (or whose email/password account got linked to an OAuth identity) could log in without the second factor. googleLogin/githubLogin now apply the same 2FA gate as password login: when 2FA is enabled they return a short-lived requiresTwoFactor challenge instead of tokens, and the client completes via the existing POST /auth/login/2fa. No full session is created until the second factor is verified.email-templates.ts palette (light canvas/card, dark text, indigo #6366f1 button) and replaced the hardcoded near-white emphasis (#fafafa) with dark #18181b so bold text is readable on light cards. Deployment/health status accents (green/red/gray) are unchanged.SettingsCard primitive (quiet bordered panel: title + muted description header, body, and an optional tinted footer bar that right-aligns the primary action). Applied consistently across Profile, Appearance, Notifications, Security, Sessions, and API Keys — all on the existing design tokens. Presentational only: hooks, handlers, and sonner toasts are unchanged; typecheck clean.AlertBox "saved" banners — consistent with the rest of the app. Removed the local saved/error state + timeouts; added the matching toasts i18n keys (EN + TR). Server/mutation errors flow through the existing global error toast.useImportSource hook plus a presentational ImportSourceStep component. page.tsx is now 462 lines (down from the original 1,489). The step's props are typed via Pick<ReturnType<typeof useImportSource>> so the compiler enforces complete prop threading. Pure refactor — state/effects moved verbatim, typecheck clean.monitoring/components/. - Server detail page: 650 → 396 lines — status banners + provider/network sections into servers/components/. - Database detail sections: split the 670-line DatabaseDetailSections.tsx into one file per component under components/databases/detail/; the original file is now a thin re-export so import sites are unchanged. - Site editor: extracted the ToolbarToggle/SectionHeading/Field helpers into site-editor/parts/; the stateful editor panels were intentionally left in the parent to avoid risky prop threading.app/docs/page.tsx): 1,445 → 247 lines. Extracted the 10 API-reference sections into app/docs/sections/ with a shared shared.ts (types + param defs). - New project page (projects/new/page.tsx): 1,489 → 1,067 lines. Extracted the step panels (ProgressSteps, ConfigureStep, EnvironmentStep, ReviewStep), EnvVariableRow, and WebhookSecretModal into projects/new/components/. The Step 1 "import source" block (deeply entangled with 25+ state values) was intentionally left in the parent for now.projects/[id]/components/ (OverviewTab, DeploymentsTab, EnvironmentTab, DomainsTab, DomainCard, NginxSettingsModal, ToggleOption, SettingsTab, NotificationsTab, HealthCheckSection, PreviewDeploymentsSection, MetricsSection). Pure refactor — no behavior change; typecheck clean.deployment:status realtime handler previously invalidated only the deployment queries; it now also invalidates the project detail query (and the domains list on first success), so the page no longer shows stale info after a deploy.GOOGLE_ENABLED/GOOGLE_CLIENT_ID/GOOGLE_SECRET and Redeploy, with the exact provider callback URL (<app-url>/auth/v1/callback) for the project. No SSH needed — the existing env-edit + redeploy flow already applies it.body overflow) and the backdrop ignores touch gestures (touch-none, overscroll-contain). The sidebar also uses h-dvh so its full height (including the user row) fits the visible viewport on mobile browsers with dynamic chrome.dark: variant was defaulting to the OS prefers-color-scheme because no @custom-variant dark was defined — so when the app theme was dark but the OS was light, those pages stayed in light styles. Added @custom-variant dark (&:where(.dark, .dark *)) so dark: utilities are driven by the .dark class set in stores/theme.ts, consistent with the rest of the app.stores/locale.ts and the Settings language control already existed; this removes the redundant public toggles.)script-src now allows https://www.googletagmanager.com and https://www.google-analytics.com, so GA4 (gtag.js) loads. (connect-src/img-src already permit https: for the analytics beacons.)llms.txt with explicit "alternative to Coolify/Vercel/Heroku/Render/Railway" framing and links to the comparison guides; added llms-full.txt — a self-contained product overview (definition, comparisons, features, quick-start, FAQ) for AI assistants doing deep research.G-SW4LNQEV9M, overridable via NEXT_PUBLIC_GA_ID). Loads in production builds only — local dev stays tracking-free.(auth) layout used to redirect any authenticated visitor to the dashboard before /accept-invitation could render, so clicking an invite link from email appeared to "do nothing". The layout now makes an exception for the invite flow, letting logged-in invitees see and click "Accept".GET /organizations/mine (lists every org the user belongs to, with their role) and POST /organizations/switch (verifies membership, then re-issues a token pair scoped to the target org). This is what lets an invited team member actually reach the inviting org's projects/servers — previously their session stayed locked to their personal org.includedInfraCreditCents is now the ceiling, not the exact grant; new getCheapestEligibleMonthlyCents() and computeIncludedCreditTargetCents(). The backfill script reuses the same dynamic target (--dry-run reports it).includedInfraCreditCents field on each plan and infraBillingService.grantIncludedInfraCredit().credit_topup ledger entries tagged metadata.bundled = true (no schema migration required).npm run backfill:infra-credit (add -- --dry-run to preview). Idempotent — only tops up organizations still below their plan allowance.No such customer) when an organization carries a Stripe customer ID created in a different mode — e.g. a leftover test-mode customer after switching to live keys. getOrCreateCustomer now verifies the stored customer exists in the current Stripe mode and transparently recreates it if it is missing or deleted.1.08, so a strengthening EUR no longer erodes the infra margin. Pricing reads the cached rate synchronously (never blocks on the network); on fetch failure it falls back to the configured floor.INFRA_FX_BUFFER_PERCENT (default 2) — safety buffer % applied on top of the live FX rate to absorb intraday swings.INFRA_PROVIDER_SURCHARGE_EUR (default 0) — flat per-server surcharge in EUR added before margin to cover provider extras like IPv4 (~0.50).INFRA_EUR_TO_USD_RATE is now the fallback/floor rate (used only when the live FX fetch fails or returns a lower value), not the primary conversion rate.PagesPanel): add, rename, delete, and switch pages.DesignGallery) template picker for swapping the whole site design.pages jsonb column (migration 0029, with backfill of existing single-page sites) and a PUT pages API; renderer emits multi-file output (index.html + per-page directories) with a shared sticky nav.getDesigns / applyTemplate) powering the editor's template picker.conf.d (not sites-available) and apply SELinux port/content labels (semanage + chcon) — fixes BYOS "SFTP: No such file" and port-not-open failures.DragOverlay preview, and animated insertion; contextual block insertion (after the selected block); polished layers-panel DnD.serverId, database disconnect.project:/server:/database: to the owning org).TRUSTED_PROXY_HOPS).sudo/ufw (ufw → firewalld → iptables, root-first).sites/site-templates.ts)./dashboard/projects/[id]/site-editor: drag-and-drop blocks (@dnd-kit), layers, palette, inspector.contentEditable) and Preview iframe mode.en / tr)./pushify-site/, asset upload (SSH → container assets).0027_project_site_editor, 0028_site_editor_theme./api/v1/servers/:id/terminal/ws) with shell session helper.deploy-{id} (colons rejected by BullMQ — fixes Site Studio launch queue errors).project_site_editor row.dash-app scope).PROCESS_ROLE split: api (HTTP/WS), worker (background jobs), all (dev).src/worker.ts entry + npm run start:worker / dev:worker.PG_POOL_MAX, idle/connection timeouts.docs/SCALING.md, docs/JENKINS_BACKEND.md).ecosystem.config.example.cjs (env from .env).X-API-Key header, route pk_live_* before JWT.pushify-* container scan.inQueue, queuePosition, queueMessage).POST /projects/:id/webhook/github/install.serverId is null (production URL / org scan fallback).