• Docs
  • Blog
  • Pricing
Get started

Application hosting

Deploy your apps.We handle the infrastructure.

Deploy apps in one place. We take the infrastructure so you can keep building.

Start deployingService docs
ApplicationsWorker NodesSecurityIntegrationsBackupsTemplatesAgentDocs

Applications

Manage your applications and environments.

New Application

storefront

Checkout, catalog, and customer API

production (4)staging (2)

checkout

draft

Payment intents and webhooks

No environments

After deploy

The app stays up.

We take it from your source to a hostname and keep it running. You stay on the product.

traveler · storefront-apitraveler · storefront-api
4f1c9aequeued
intakegit· repo · branchimage· any registryarchive· zip · tar · tar.gz

Runtimes

Bring the stack you already use.

We find it and run it. Switch the builder only if you need to.

detectdetect
11

01 · stack

Next.js

detected

builder · railpack

Deploy options

Start from what you already have.

A repo, an image, or a zip. Same production path. GitHub and GitLab can auto-deploy.

manifest07
  1. Connect a repo and a branch, point at an image you already publish, or upload a zip / tar / tar.gz from 1KiB to 30MiB. Detect, build, run. Same steps for all three.

    gitimagearchive
  2. GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea can all be a git source on the service. Auto-deploy on every push is a webhook, and that webhook exists for GitHub and GitLab only.

    webhook

    • GitHub
    • GitLab

    source

    • Bitbucket
    • Azure DevOps
    • Gitea
  3. Those two connect as full integrations, so a push can ship. Turn on Require Approval Before Deploy when a human should sign off first. Bitbucket, Azure DevOps, and Gitea stay per-service git sources. They do not auto-deploy on push.

    webhook

    • GitHub
    • GitLab

    source

    • Bitbucket
    • Azure DevOps
    • Gitea
  4. Docker Hub, GHCR, ECR, or any private registry through a stored Docker registry account. dFlow pulls, runs, and routes it. No builder because the image is already built.

    Docker HubGHCRECRprivate
  5. Detect with Railpack. Bring a Dockerfile when you want the file. Static serves a folder. BuildPacks when you need them. Override install, build, and start when detect is wrong.

    RailpackDockerfileStaticBuildPacks
  6. Set CPU, memory, and replicas per process. Caps are 0.5–2 CPU, 512–4096 MB, and 1–5 replicas. Types are web, worker, and scheduler.

    webworkerscheduler
  7. Customers reach the app on a hostname. Add your domain when you are ready. We add the certificate. Unlimited custom domains per service.

    up.dflow.sh

ready

Bring the app.We run it.

A repo, an image, or a zip. We detect, build, and keep it running. GitHub and GitLab can auto-deploy. The other git hosts you connect yourself.

stub

detect→build→live

storefront.up.dflow.sh

Start deploying
  • GitHubOpens in a new tab
  • DiscordOpens in a new tab
  • LinkedInOpens in a new tab
StatusOpens in a new tab

Product

  • Pricing
  • Application hosting
  • Database hosting
  • Template hosting
  • AI workflow

Resources

  • Features
  • How it works
  • DocsOpens in a new tab
  • dFlow MCPOpens in a new tab
  • Blog
  • Changelog
  • Roadmap
  • Feedback
  • Developers Hub
  • dFlow vs.

Company

  • Enterprise
  • Partners
  • Join dFlow
  • Startup program
  • Affiliate program
  • Trust Center
  • Brand
  • Contact

Use cases

  • All use cases
  • Web applications
  • APIs and services
  • Data services
  • Workers and cron
  • AI apps and agents
  • Internal tools
  • Replace DIY cloud stack
  • Leave Kubernetes overhead
  • SOC 2Coming soon
  • Australian DPA
  • GDPR
  • Moving our trust centerOpens in a new tab

© 2026 dFlow

  • Privacy
  • Cookies
  • Terms
  • AnalyticaOpens in a new tab