Dply

Platform tour

Everything in one operating model

Dply connects who is allowed to work (organizations), what they can touch (credentials and servers), and how apps go live (sites, SSL, git deploys, and hooks)—without scattering secrets or SSH config across laptops.

The same developer-first idea as Git-centric platforms (e.g. bohr.io): spend energy on product code, not on re-creating deploy plumbing—while you keep the servers.

If you define cloud resources with infrastructure as code (e.g. Pulumi in TypeScript, Python, or Go), Dply sits next to that workflow—see the section on platform ops below.

How it works together

Data and permissions flow through a single hierarchy—so onboarding a teammate never means forwarding API tokens.

  1. 1

    Organization

    Every resource belongs to an org. Switch context, invite people, and align billing to the team that owns the infrastructure—one subscription covers every server and every site in that org.

  2. 2

    Credentials

    Cloud API tokens live in the vault, scoped to the org. Members run workflows without copying secrets into local env files.

  3. 3

    Servers

    Provision from supported clouds, or register any box over SSH. One inventory for commands, health checks, databases, cron, processes, and firewall rules.

  4. 4

    Sites

    Map domains to runtimes (PHP, Node, or static). Nginx, TLS, git remotes, env files, and deploy automation stay attached to the server they run on.

  5. 5

    Ship & operate

    Trigger deploys from git hooks or your CI. Run ad-hoc commands, review deployment output, and adjust worker and firewall config from the same console.

Mental model: the organization is the trust boundary. Credentials never leave it; servers and sites inherit it; every action is tied to a member who is already authenticated into that org.

Code more, manage less—on your metal

Git-first workflows, not a black-box host

Platforms like bohr.io emphasize GitHub-integrated deploys and a smooth path from repo to production. Dply brings that same mental model—OAuth to GitHub, GitLab, and Bitbucket for source control, signed deploy webhooks, and per-environment configuration—while your workloads run on servers and credentials you own (BYO or cloud-provisioned).

  • Same deploys from UI, git, or CI

    Trigger deploys from the dashboard, from a signed webhook after a push, or from your pipeline using organization-scoped API tokens—granular abilities, same operations the app uses.

  • Frontend and backend in one org

    Run static and Node sites next to PHP apps (Laravel and others) on the same inventory—domains, TLS, and env stay next to each site.

  • Secrets that stay in the platform

    Deploy keys, webhook secrets, and env payloads are encrypted at rest; teammates collaborate through the org instead of passing keys in chat. When you need the box, SSH and remote commands are still there.

Vibe coding · then production

Not an AI website generator—operations for code you own

YouWare and similar products focus on “vibe coding”: chat with AI to spin up landing pages, dashboards, prototypes, internal tools, Figma-to-site flows, and more—often with hosting, credits, and built-in AI APIs so creators can ship fast without touching servers.

Dply does not replace that experience. We do not generate sites from a prompt or run a no-code app builder. We are the ops layer when you are ready to run real repositories on infrastructure you control: git deploys, TLS, org-scoped secrets, teams, backups, and the same server inventory your engineers SSH into.

Many teams use both kinds of tool—a fast AI builder for experiments or marketing surfaces, and Dply for the product that needs predictable deploys, audit trails, and BYO compliance boundaries.

  • YouWare-style: ideate fast

    Describe a page or app in chat, get responsive UI, prototypes, or Figma-driven output—great for velocity before you commit to a repo and runtime.

  • Dply: operate for real

    Wire git, webhooks, and APIs to servers you pay for; keep env and keys in the org vault; roll out with releases and rollback.

  • Same company, two speeds

    Landing pages or demos from an AI builder; customer-facing APIs and apps on Dply—without pretending one product is the other.

Infrastructure as code · then what?

Complements IaC platforms like Pulumi

Pulumi is a modern infrastructure-as-code platform: real languages (TypeScript, Python, Go, .NET, Java, YAML), provider registry, centralized secrets and configuration (e.g. Pulumi ESC), governance and insights, and patterns for internal developer platforms—so teams can define and provision cloud resources as software.

Dply is not a drop-in replacement for Pulumi or Terraform: we do not compile arbitrary multi-cloud infrastructure graphs from your repo. We are the operations control plane for the servers and sites your team actually runs—whether those VMs or networks were created with Pulumi, by hand, or through our built-in provider integrations.

  • Same automation ethos

    Granular HTTP APIs and org-scoped tokens mirror the “scriptable platform” expectation—CI and services can trigger the same deploys and server actions as the dashboard.

  • Secrets & governance

    Provider credentials and app secrets live encrypted in the org vault; audit trails record infrastructure actions—aligned with platform engineering discipline, scoped to application delivery.

  • Typical split of responsibilities

    Use Pulumi (or similar) for durable cloud definitions; use Dply for SSH-backed sites, TLS, git deploys, databases, cron, firewall, and team workflows on those machines.

CI is not CD

Deploy & releases — alongside tools like Octopus

Octopus Deploy is built for continuous delivery at scale: take over after your CI server, orchestrate releases across environments, model runbooks and tenants, target Kubernetes and multi-cloud hosts, and enforce RBAC and compliance—addressing the gap that “CI is not CD” (build pipelines alone are not full delivery).

Dply covers the application deploy side for servers and sites you own: signed webhooks and org-scoped APIs to trigger deploys, deployment history, atomic releases with rollback, and per-site environments and encrypted env—so your CI (GitHub Actions, Jenkins, GitLab CI, etc.) can build and test while we push to the runtime over SSH.

We are not a drop-in replacement for Octopus: there is no tenant-per-customer deployment model, no first-class Kubernetes control plane, and no runbook product as rich as theirs. If you need enterprise-grade release orchestration across many clusters and teams, Octopus remains in that category; if you need a focused BYO-server path from git to production with a clear audit trail in the org, that is Dply.

  • CI builds, Dply deploys

    Keep CI where it belongs—compile, test, static analysis—then trigger a deploy with the same webhook or API your pipeline would call manually.

  • Releases you can roll back

    Track deployments and flip the current symlink to a prior release when something goes wrong—without inventing glue scripts per app.

  • Octopus-scale CD

    For multi-team, multi-cluster, compliance-heavy promotion pipelines, products like Octopus are purpose-built; Dply stays focused on your org’s servers and sites in one control plane.

Organizations & people

Multi-tenant by design—your production org stays separate from personal experiments.

  • A

    Org-scoped data

    Servers, sites, credentials, and billing roll up under the active organization. Switch orgs from the app when you belong to more than one.

  • B

    Invitations

    Bring teammates in through secure invite links so access is granted in-app—not over Slack with raw tokens.

  • C

    Billing per organization

    Plans attach to the org. Subscription limits apply organization-wide—every server and every site under that org shares the same plan. There is no separate per-site product line on your invoice.

  • D

    Activity visibility

    Review recent organization audit entries—who did what—so changes to infrastructure are easier to trace.

  • E

    Your account follows you

    Profile, password, verified email, two-factor authentication, and OAuth sign-in (e.g. GitHub, GitLab, Bitbucket when enabled) live on your user—not on each organization or site. The same settings apply everywhere you have access.

Plans cover the whole organization

Usage limits we enforce from your plan (for example, how many servers you can connect, and how many sites the org may create on those servers before upgrading to Pro) are counted for the entire org. Billing is not split per application or hostname.

Profile, 2FA, and OAuth are personal

You sign in as a person. Hardening your account with 2FA, linking an OAuth provider, or updating your profile applies to all organizations you belong to and every site you can reach through those memberships—without reconfiguring security per team.

Credentials & clouds

Connect the APIs that create and manage infrastructure. Tokens are validated when possible, then stored encrypted—your team uses them through Dply, not from plaintext notes.

Full provisioning support

Create and tear down compute from the panel (where the integration is complete), including:

  • · DigitalOcean, Hetzner, Linode, Vultr, UpCloud, Scaleway
  • · Equinix Metal, Akamai (Linode), Fly.io, AWS EC2

Custom & roadmap providers

Attach any server with SSH when you already have hardware or a provider we have not wired for provisioning yet.

Additional provider accounts (e.g. Render, Railway, GCP, Azure) can be stored as credentials for future workflows as integrations expand—your labels and vaulting model stay the same.

Servers & day-two operations

After a machine exists—cloud or custom—the server record becomes your control plane: run commands, declare dependencies, and keep access tidy.

Remote execution

Run shell commands from the dashboard over SSH—ideal for quick fixes without distributing keys to every laptop.

Health checks

Point at an HTTP endpoint and let the platform track whether your service answers—so status lives next to the server, not in a separate monitor.

Databases

Record database connections your apps rely on (engines like MySQL), kept alongside the server that hosts them.

Cron & workers

Model scheduled jobs and Supervisor programs (queues, workers) so long-running processes are documented and reproducible.

Firewall rules

Open or restrict ports with intent—pair network policy with the same server your team already uses for deploys.

SSH keys & recipes

Manage authorized keys centrally and run setup scripts (“recipes”) when you need a repeatable bootstrap beyond the default image.

Sites, TLS & deploys

A site is how traffic reaches your code: hostname, runtime, document root, and deployment settings—all bound to a parent server.

Runtimes

PHP (PHP-FPM), Node behind a reverse proxy, or static/HTML—pick the stack that matches the app.

Nginx & SSL

Provision vhosts and track certificate status so HTTPS is part of the site lifecycle, not a weekend chore.

Git & webhooks

Wire a repository and branch, keep deploy keys in the vault, and trigger builds from git push via a signed webhook—CI can call the same hook when you are ready.

Laravel-friendly options

When the app needs it: Octane ports, scheduler toggles, per-environment .env content, post-deploy commands, release retention, and extra Nginx snippets—configured next to the site, not scattered across playbooks.

Transparency vs Forge-style panels

Laravel Forge-style products make Laravel deploys easy but are sometimes criticized for feeling like a black box when you need non-standard stacks or deeper access. Alternatives such as Serversinc (vs Forge) emphasize Docker per app, flat platform pricing, and your own VPS—trading Forge’s opinions for containers and control.

Dply goes after the same goals—full control, predictable org billing for the product, and infrastructure you pay providers for directly—with a VM-first model: Nginx, PHP-FPM, Node, and static sites on the server over SSH, plus git deploys, env management, and optional extra config. We do not require every app to be packaged as a Docker image; if you standardize on Compose or other tooling on the box, you can still drive it through SSH and automation—first-class flows are traditional stack + releases, not orchestration inside the panel.

What teams ask for In Dply
Escape the black box SSH, server recipes, Nginx snippets, and explicit paths—so tuning is visible, not hidden.
Predictable platform cost Subscription is per organization and covers every server and site in that org under plan limits; you pay clouds or VPS vendors separately—similar “platform + your infra” clarity to flat-fee comparisons like Serversinc’s Forge page.
Not only Laravel PHP, Node, and static site types; Laravel-first conveniences (scheduler, Octane, env) without locking the whole org to one framework.
Docker-first (e.g. Serversinc) Optional on your server—Dply does not mandate a container image per app. Prefer Docker everywhere? Run it on the VM and use the panel for coordination, secrets, and deploy triggers, or pair with a container-centric host.

Same lane as ServerPilot: your cloud, your root

ServerPilot popularized bring-your-own-server management: connect VPS from any provider, keep root access, run apps with Let’s Encrypt SSL, multiple PHP versions, Nginx (and Apache where offered), firewall defaults, monitoring dashboards, and migrations between servers—plus a dashboard/API so you are not stuck in a single vendor’s “managed” cage.

Dply shares that core promise: your servers, your providers, and a control plane for sites, TLS, PHP-FPM, Node, static assets, databases, cron, and firewall rules. We drive configuration over SSH (and cloud APIs when you provision through us)—we do not claim the same agent architecture or Apache+.htaccess stack ServerPilot markets; advanced host metrics dashboards and one-click cross-server migrations are not first-class products here today—use health checks, backups, and manual or scripted moves until dedicated flows exist.

Where we often go further for product teams: git-native deploys, atomic releases, organization RBAC, audit logs, and granular HTTP APIs—closer to a platform engineering surface than a PHP-only panel.

ServerPilot-style theme In Dply
Any provider · root Supported — cloud provisioning integrations plus Custom servers with SSH; you retain provider access and keys in the org vault.
Apps · SSL · PHP Supported — sites, Certbot/Let’s Encrypt, per-site PHP and paths; Node and static in addition to PHP.
Nginx · performance stack Supported — Nginx vhosts and optional snippets; no bundled Apache front door for .htaccess—tune via Nginx or server recipes if you need Apache semantics.
Firewall · hardening narrative Partial — declarative UFW rules from the panel; OS auto-updates and “no exposed management ports” are your image/provider unless you encode them in bootstrap scripts.
Metrics dashboards Partial — HTTP health checks and status; not the same as ServerPilot-style full host metrics UI.
Migrations between servers Operational — use SSH, backups, and deploys; no dedicated “move app wizard” like some classic panels advertise.
WordPress one-click Partial — run WordPress as a PHP site; no WP-specific installer in the panel today.

Coverage vs panels like SiteKit

Dply is a control plane that drives your servers over SSH and provider APIs—similar in scope to panels that advertise a full LEMP/LAMP stack, Git deploys, and security tooling. The categories below mirror what you see on open-source server panels such as SiteKit, so you can compare feature-for-feature. We do not ship a resident agent or a single-line OS bootstrap; instead we integrate with clouds you already use or any box you can SSH into.

Supported Partial / different model Roadmap / use recipes

Area In Dply
Server provisioning Supported — create or destroy servers via DigitalOcean, Hetzner, Linode, Vultr, UpCloud, Scaleway, Equinix Metal, Fly.io, AWS EC2, and more; attach Custom servers with SSH. Different — we do not install a lightweight agent or run a curl | bash full-stack bootstrap; the OS and packages are yours or your cloud image.
Git deployments & rollbacks Supported — git remotes, signed webhooks, deploy hooks, atomic deploys with releases/ and rollback to a prior release.
PHP / Laravel / Node / static Supported — site types for PHP-FPM, Node reverse proxy, and static; Laravel-oriented options (scheduler, Octane, env, caches in deploy scripts).
WordPress Partial — deploy PHP apps and custom scripts; there is no dedicated WordPress provisioning wizard or WP-CLI panel in BYO today. Treat WordPress like any PHP site or automate with deploy scripts.
Databases (MySQL, MariaDB, PostgreSQL) Supported — create databases and users on the server over SSH (MySQL/MariaDB and PostgreSQL paths in provisioning).
Redis Roadmap / ops — install and configure Redis on the server outside the dedicated DB wizard, or encode it in server recipes.
SSL (Let’s Encrypt) Supported — Certbot over SSH for site domains; renewal follows your server’s certbot setup.
Firewall (UFW) Supported — declarative rules per server synced to ufw allow patterns.
Cron & Supervisor (workers) Supported — managed crontab blocks and Supervisor programs tied to servers and sites.
Environment variables Supported — per-site environment rows stored in the app (encrypted at rest) and applied in deploy flows.
Monitoring (CPU / RAM / disk) Partial — HTTP health checks and server status in the control plane; not a bundled host metrics agent with live graphs like a full APM stack.
Fail2Ban, unattended upgrades, hardening Partial — TLS and Nginx configuration from the panel; OS-level hardening (Fail2Ban, unattended-upgrades) is left to your image or run via remote commands/recipes.
SSH keys Supported — account SSH keys with optional deploy to authorized_keys, plus per-server key records.
Backups Supported — backup configuration for files and databases (see Backups in the app).
Teams & audit Supported — organizations, teams, invitations, roles, and audit log entries for infrastructure actions.
Alerts (email, Slack, webhooks) Partial — notification channels and events exist; wire the channels your org uses so deploy and uptime events reach the right place.

Security & account hygiene

Enterprise-style products need more than a password—here is how Dply keeps keys and sessions under control.

  • Encrypted secrets

    Sensitive fields (deploy keys, webhook secrets, env payloads) are encrypted at rest so the database alone is never enough to impersonate your infrastructure.

  • Two-factor authentication

    Turn on 2FA once in your profile—it protects your login across every organization and site you can access, not just one workspace.

  • OAuth sign-in

    Link GitHub, GitLab, or Bitbucket (when your app enables them) to your user account. The same identity signs you in everywhere; org roles still decide what you are allowed to change.

  • Verified email & profile

    A verified address is required for dashboard access. Name and profile settings live on your user—they do not reset when you switch org context.

See it in your account

Guided docs walk through connecting a provider and creating your first server. The same flows power everything above.

Create free account Compare plans