Which Firebase Hosting alternative fits your sites and your servers
Coolify or Dokploy can serve static sites and web apps on servers your team controls, and Appwrite Sites fits teams that already run Appwrite for authentication and data. If your renewal, Blaze plan dependency or data residency rule is pushing hosting into your own cloud or data center, the first decision is whether the sites need a separate deployment platform or should sit next to the backend they call. Coolify connects to each server over SSH and deploys from a Git repository or a prebuilt image, with its Static build pack for plain sites. Dokploy offers Static sites served from an NGINX container and a Static build type alongside Nixpacks and Dockerfile builds. Appwrite Sites keeps hosting, auth, database and functions inside one Appwrite installation, which reduces the number of systems to operate but ties hosting to Appwrite's release cadence.
Before choosing, export your Firebase Hosting configuration and confirm it. Firebase Hosting's exact feature set depends on your own firebase.json file, so list every rewrite, redirect, header rule, preview channel and custom domain it actually uses. Check which of these you rely on for single-page app routing, and whether any rewrite points to a Cloud Function, because that link must be rebuilt on the new platform rather than copied. Confirm the licensing position with your procurement team too: Dokploy's proprietary directories carry a separate license, so its enterprise features need a review before you rely on them.
Plan for who will run the servers. Coolify needs at least 2 CPU cores, 2 GB of RAM and 10 GB of free disk, and Dokploy needs at least 2 GB of RAM and 30 GB of disk, so confirm the sizing against your traffic and any other workloads. Your team pays for the servers, the operating system patching, certificate handling and backups, and these recur every month. Ask any implementation partner for a written scope that names each site, its build method, its redirects and its domain cutover order, so the one-time migration effort is visible before work begins.
How Firebase Hosting features map to Coolify, Dokploy and Appwrite Sites
This table compares each Firebase Hosting capability with what Coolify, Dokploy and Appwrite Sites document today. Where the documentation is silent, the cell says what to confirm in a test project before cutover, and where a gap needs a custom proxy rule, the cell says so. Read it as a checklist for the migration plan, not a substitute for testing each rule against your own domains.
| Capability | Coolify | Dokploy | Appwrite Sites |
|---|---|---|---|
| Static file serving | Static build pack serves built output through the proxy | Static sites served from an NGINX container | Static hosting is part of Sites; confirm build output settings for your framework |
| Git or CI deploys | Deploys from Git repositories; GitHub App or webhook can trigger builds | Git builds through Nixpacks, Railpack or Dockerfile; confirm trigger setup in your version | Confirm the Git connection and deploy triggers in the Console for your version |
| Preview environments | Builds pull and merge requests at a default {{pr_id}}.{{domain}} URL; needs wildcard DNS | Preview deployments are documented; confirm the URL pattern and DNS requirements | Not covered in the documentation reviewed here; test preview URLs before relying on them |
| Custom domains | Assigned per application and routed by the coolify-proxy container | Routed through Traefik, which listens on ports 80 and 443 | Confirm domain verification and DNS steps for each Sites deployment |
| TLS certificates | Traefik or Caddy issue HTTPS automatically; Custom (None) leaves TLS to the operator | Traefik handles HTTPS routing; confirm certificate issuance for each custom domain | Confirm certificate provisioning and renewal for both self-hosted and cloud Sites |
| Redirects | Usually a custom proxy rule; confirm the Traefik or Caddy syntax for your version | Custom NGINX or Traefik configuration; confirm which method your version supports | Confirm whether redirects are configurable; otherwise define them in the app build |
| Rewrites to functions | Needs a custom proxy rule to a separate function service; no built-in equivalent documented | Needs a custom route or NGINX rule to a backend service | Functions have their own endpoints; confirm whether Sites can rewrite paths to them |
| Rollback | Redeploy an earlier build; confirm how many past builds and images are retained | Redeploy a previous build; confirm how deployment history is kept | Confirm deployment history and the redeploy steps in the Console |
Choosing between Coolify, Dokploy and Appwrite Sites
Each option can take over static sites and web apps from Firebase Hosting, but they differ in what they install, how they handle licensing and how much they expect you to run. The cards below compare them on fit, trade-off and the checks to make before production use.
Coolify for static sites on your own servers
Coolify is licensed under Apache-2.0 and its self-hosted edition is described as free forever with all features. It connects to your servers over SSH, prepares them for Docker, and deploys from a Git repository using the Static build pack. Each server runs one coolify-proxy container, with Traefik as the default and Caddy as the alternative, and both handle HTTPS automatically. The trade-off is that you own the servers, patching and the proxy configuration. Before cutover, confirm how redirects and rewrites are expressed in your chosen proxy, since Firebase's firebase.json rules do not carry over automatically.
Dokploy with a source-available enterprise layer
Dokploy's license applies Apache License 2.0 to code outside its /proprietary directories, but that directory falls under the Dokploy Source Available License 1.0, which allows production use only under a commercial agreement. Its Static build type serves sites from an NGINX container, and its installer sets up Docker Swarm with Traefik on ports 80 and 443. It fits teams that want a Heroku-style panel and expect to need SSO or audit logs later. Check whether those enterprise features sit in the proprietary directory before you rely on them, and read the terms on resale if you plan to host sites for clients.
Appwrite Sites inside a full backend stack
Appwrite Sites is part of the BSD-3-Clause Appwrite platform, so one install covers hosting next to Auth, Databases, Storage and Functions. This suits a team that will move the backend along with the front end. The cost is a heavier install: the installation guide asks for 2 CPU cores, 4 GB of RAM, 2 GB of swap and Docker Compose version 2, and the sample Compose file runs PostgreSQL, Redis, Traefik, ClickHouse and several workers. Confirm the static hosting path and custom domain setup on the version you install, since Sites is only one part of the stack.
Which host to pick by team size and deployment shape
A small team with one or two Linux servers and no dedicated platform engineer usually fits best on Coolify. It connects to each server over SSH, prepares it for Docker workloads and deploys static sites from a Git repository through its Static build pack, with the proxy handling HTTPS automatically. Coolify's installation docs list at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and the self-hosted edition is Apache-2.0 licensed with no feature limits.
- Setup effort: Installation is a single script on a supported Linux distribution. Most of the work is DNS, the first static site and the redirect and rewrite rules you carry over from Firebase Hosting.
- Server requirements: At least 2 CPU cores, 2 GB RAM and 10 GB free disk, on amd64 or arm64.
- Routing and TLS: The default Traefik proxy or Caddy handles certificates automatically. Confirm that your rewrite rules can be expressed in the proxy configuration you choose.
- Recurring cost: Your servers and their backups. Coolify's managed Cloud option is priced per connected server on its pricing page, so ask whether a managed control plane is worth it for your team.
- Previews: Pull request previews need wildcard DNS for the default URL pattern.
Before choosing, confirm that one host is enough for your traffic and that someone on the team can patch the server and the proxy.
A platform team running several servers, or planning a Swarm cluster, should compare Coolify with Dokploy. Dokploy is built on Docker and Traefik, its installer sets up Docker Swarm, and its documentation recommends vertical scaling before horizontal scaling because horizontal scaling needs more configuration. Its licensing has a split: code outside the /proprietary directories is Apache 2.0, while enterprise features such as SSO, SCIM and audit logs fall under a source-available license that requires a commercial agreement for production use.
- Setup effort: Dokploy needs more planning for clusters, including Swarm manager and worker nodes and a Docker registry to distribute images.
- Server requirements: At least 2 GB RAM and 30 GB disk, tested on specific Ubuntu, Debian, Fedora and CentOS releases.
- Licensing: Check which features your team needs, because SSO, SCIM and audit logs are outside Apache 2.0.
- Multi-server model: Coolify also deploys to remote servers over SSH, so compare how each handles the number of servers you run.
- Recurring cost: Servers, registry storage, backups and the people who maintain the cluster.
Confirm your licensing position with Dokploy directly, and test the cluster behavior you rely on before standardizing on either tool.
A team that already runs self-hosted Appwrite for auth, databases and functions can host its static sites in Appwrite Sites, so the frontend, backend and domains sit in one place. This avoids a second hosting tool, but it ties site hosting to the Appwrite install and its resource needs. Appwrite's installation guide requires 2 CPU cores, 4 GB RAM, 2 GB swap and Docker Compose version 2, and the current release is 2.5.0.
- Setup effort: Low if Appwrite is already running. Confirm that the Sites feature is enabled in your installed version and configure the domains and redirects.
- Server requirements: The Appwrite stack's minimums, which are higher than Coolify's or Dokploy's, so size for the whole platform.
- Operations: Appwrite's Helm chart docs note that built-in datastores run a single replica without failover, so a production install needs managed services or operators for those components.
- Upgrades: Appwrite releases often, so plan upgrades for the platform that also serves your site.
- Recurring cost: Mostly the existing Appwrite servers, plus any managed datastore you add.
Confirm that the Sites feature covers the redirects, rewrites and header rules your Firebase Hosting configuration uses before moving the site.
What redirects, rewrites and TLS need from the team
Firebase Hosting handles redirects, rewrites and certificates as part of the service, so the team rarely configures them directly. On Coolify, that work moves to the platform and the operator. Each server runs one coolify-proxy container, and the proxy choice decides who handles routing and certificates. Traefik is the default and Caddy is the alternative, and both issue HTTPS certificates automatically. The Custom (None) option leaves routing and TLS certificates to the operator. Before cutover, confirm which proxy the server runs, check that the custom domain resolves to it, and confirm the certificate is issued for every hostname the Firebase site served, including the bare domain and any www variant.
Preview deployments add a DNS requirement that Firebase Hosting users may not have planned for. Coolify builds pull or merge requests from GitHub, GitLab, Gitea and Bitbucket at a default {{pr_id}}.{{domain}} URL, and that pattern needs wildcard DNS pointing at the server. Wildcard records and the certificate covering them must be in place before previews work, and the team should decide whether preview hostnames are public or restricted. Coolify deletes preview deployments when the request is closed or merged, so teams that rely on long-lived review URLs need to plan around that.
Anything Firebase Hosting did through its configuration file must be recreated by hand. Redirects, rewrites for single-page apps and any rewrite that forwarded a path to a Cloud Function have no automatic equivalent. A rewrite to a function must instead point to a service the team runs, such as an Appwrite or Supabase function endpoint, or to a reverse proxy rule the team writes. Inventory every rewrite and redirect in the Firebase configuration, assign each one a destination, and test cache headers and trailing-slash behavior on a staging hostname before DNS changes. Confirm these rules with the team that owns the proxy configuration, since they will own them after the move.
Running self-hosted sites beside Firebase Auth, Firestore and Functions during cutover
Moving hosting off Firebase rarely happens in one step, so the site, the backend and the domain move on different timetables. Each of the four decisions below creates a dependency that can break a live app if it is not tested, and the team should decide each one explicitly before the first DNS change.
Keeping Firebase Auth and Firestore
The most common first step is to move only the static build or web app to Coolify or Dokploy while the client keeps calling Firebase Auth and Cloud Firestore directly from the browser. The coupling risk is that the new host's origin, domain and Content Security Policy must match the Firebase authorized domains and API key restrictions, or sign-in silently fails. Test sign-in redirects, token refresh and Firestore security rules from the new domain before cutover, and confirm which Firebase services still bill during the overlap.
Pointing sites at Appwrite or Supabase
If the frontend is switched to a self-hosted backend in the same release, every client SDK call, auth token and storage URL changes at once. Auth users may need migration first, and Firebase password hashes only carry over if the new platform accepts the same hash parameters. Keep the old SDK configuration in a build flag so a rollback restores Firebase without a rebuild, and test each user path, including password sign-in and file access, against the new backend.
Routing to Firebase Cloud Functions
During transition, a rewrite on the new host can forward paths such as /api to existing Firebase HTTPS functions, so the front end keeps one origin. The risk is hidden latency, cross-origin cookie behavior and the fact that Cloud Functions for Firebase requires the Blaze plan, so the bill continues while the old functions run. Confirm that the rewrite preserves methods, headers and request bodies, and that function authentication still checks Firebase ID tokens correctly.
Managing DNS cutover and rollback
Lower the TTL on the records for the production hostname well before the change, then point the domain at the new Coolify or Dokploy server and keep the Firebase Hosting configuration in place until the new site has run cleanly. Coolify and Dokploy both handle HTTPS through Traefik, and a missing certificate or unchanged redirect rule can break the cutover. Write down who can revert the record, how long the old TTL takes to clear, and which checks decide the rollback.
Migrating Firebase Hosting sites in steps
This sequence moves each Firebase Hosting site onto a self-hosted target with its redirects, rewrites, headers and domains rebuilt and tested before any DNS change reaches visitors. The output is a decommission-ready Firebase site with a documented, verified replacement.
Inventory the firebase.json hosting configuration
Start by reading every hosting target in firebase.json and recording each site, its public directory, redirects, rewrites, headers and attached custom domains. Confirm the list against the Firebase console, since a config file can differ from what is live. Rewrites that call Cloud Functions or Cloud Run need a decision: they must be moved to an endpoint you run, or the route will break. The engineering owner signs off on this inventory, and a second reviewer checks it against live traffic logs if your team can export them. The step is done when every rule has a named destination on the new platform or a documented reason for removal.
Choose the build path for each site
For each site, decide whether the build runs as a Static build pack, a Dockerfile, or a Dokploy static site served from an NGINX container. Coolify's Static build pack and Dokploy's Static option both suit prebuilt output, while sites that run a build step on deploy need Nixpacks, a Dockerfile or a Docker image. Confirm which build tool and Node version each site needs, because hosting configuration does not carry that information. The application owner and the platform engineer decide together, and the outcome is a written build definition per site that a teammate can rebuild from a clean checkout.
Deploy to a staging domain
Deploy each site to a temporary hostname on the new platform and confirm the build finishes and serves the same files Firebase Hosting serves today. Compare the published output with the last Firebase release, checking asset hashes, the 404 page and single-page app fallback behavior. Staging domains depend on wildcard DNS for preview URLs in some platforms, so confirm that setting first. The platform engineer owns the deployment, and the site owner checks key pages. The step is complete when the staging build matches the production release and the team can redeploy it from Git.
Configure TLS and DNS for the target domains
Add the custom domains to the new platform and confirm how certificates are issued. Coolify's default Traefik or Caddy proxy handles HTTPS automatically, while a Custom (None) proxy leaves certificates to your team. Dokploy routes through Traefik on ports 80 and 443, so confirm those ports are reachable and not used by another service. Prepare DNS records at the registrar in advance, but do not point production traffic yet. Confirm with your DNS owner that TTL values are lowered before cutover, and record the certificate issuer and expiry date for each domain. The step is done when every domain presents a valid certificate on the staging path.
Test redirects, rewrites and headers
Run a test list that covers every redirect, every rewrite and each response header from the inventory, using both the staging domain and the production hostname with a local host entry. Check status codes, destinations and caching headers, and include trailing-slash variants and query strings. Rewrites to functions or APIs need the same test against the backend they now reach, since a route that returns the page shell but not data is a failure. The QA lead owns the test list, and an engineer outside the project should run it to catch assumptions the original team stopped noticing. The step is done when every test passes and results are saved.
Cut over DNS and monitor the first traffic
Change the DNS records to the new platform during a window your operations team has agreed, keeping the Firebase Hosting site live until traffic has moved. Watch error rates, 404 counts, certificate warnings and the key user journeys for a period agreed beforehand. Keep the Firebase rollback path documented, which means the original DNS values and the Firebase deploy command, until monitoring is clean. The incident owner and the product owner share this responsibility, and the step closes when the monitoring period ends with no open regressions.
Decommission Firebase Hosting and record the change
After monitoring closes, remove the Firebase Hosting targets, detach the custom domains from the Firebase project and archive the final firebase.json. Confirm with your billing contact whether any Firebase services are still in use in the same project, because hosting removal does not remove other products. Record the new architecture, build definitions, certificate renewal owner and rollback notes in your runbook. The platform owner signs the change record, and the step is done when Firebase Hosting no longer serves any domain and the runbook names an owner for renewals and updates.
What a Firebase Hosting migration costs and who does the work
What are the cost components of moving off Firebase Hosting?
The cost falls into a few parts: the server or managed-platform fee, the staff time to set up and rewrite routing, DNS and certificate work, and the one-time rewrite of any redirects, rewrites to functions and build settings. Firebase Hosting bills by storage and transfer, so the new cost is mostly fixed infrastructure plus labor. Self-hosting Coolify is free software, so your cost is the servers and the people who run them. Coolify Cloud charges $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. Dokploy's Hobby tier lists $4.50 per month per server, according to its pricing page. Ask any vendor or partner to split the quote into these parts so you can see which ones recur.
What recurs after a static site moves to Coolify or Dokploy?
Recurring costs are the servers, backups, patching, certificate renewals and upgrades. Coolify and Dokploy both run on Docker, and their proxies (Traefik by default in Coolify, Traefik in Dokploy) manage HTTPS on hosts you control, so someone must keep the host operating system, Docker and the proxy current. Coolify's own upgrades move between versions such as v4.4.6, released on October 9, 2026, and Dokploy's v0.30.8, released on September 29, 2026, so plan a recurring upgrade window. Static sites need little database work, but if you add a database through either tool, its backups become a recurring duty, and Coolify's scheduled backups do not cover Redis, Dragonfly or KeyDB. Confirm your monitoring and on-call coverage with the team that will own it.
Can our team migrate Firebase Hosting alone?
A team with Linux and Docker experience can migrate a small set of static sites alone, because Coolify installs with a single script and its Static build pack serves prebuilt output. The work becomes harder when you have many sites, custom redirect or rewrite rules that Firebase's firebase.json handled, or cross-site dependencies. Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on each server, and Dokploy needs at least 2 GB RAM and 30 GB of disk, so confirm that your hosts meet these minimums before you start. Ask your engineers whether anyone has owned TLS and DNS cutovers before, since a mistake there causes downtime that is hard to diagnose.
How long does a Firebase Hosting migration take?
The duration depends on the number of sites, how many routing rules and redirects each one has, how many environments need preview builds, and how much DNS and TLS work is involved. No duration figure has been supplied for this migration, so confirm it with your engineering lead or with any consultant against your own site inventory. A useful starting point is a count of sites, custom domains, rewrites to functions and preview-deployment needs. Coolify's preview deployments need wildcard DNS, and that setup can add time if your DNS provider or team process is slow. Ask for a schedule that separates a pilot site from the full cutover.
Do Coolify Cloud or Dokploy's paid tiers change the cost picture?
They can, if you prefer managed hosting for the control plane rather than running it yourself. Coolify Cloud runs the Coolify instance on its managed infrastructure while you bring your own servers, and it costs $5 per month for 2 connected servers plus $3 per month for each additional server, according to Coolify's pricing page. Dokploy's Startup tier starts from $15 per month with up to 3 servers and basic RBAC, and its Hobby tier is $4.50 per month per server, according to Dokploy's pricing page. Dokploy's SSO, SCIM, audit logs and SLA sit in its Enterprise tier, which is priced on request, and those features are source-available under a commercial agreement rather than Apache 2.0. Compare these fees with the staff time saved by a managed control plane, and confirm that the licensing terms fit your use.
What should we ask a consultant for in a fixed-scope quote?
Ask for a written scope that lists each site, custom domain, redirect and rewrite rule, and each function that a site calls, plus the target platform and server count. Request deliverables such as a configured proxy, TLS and DNS cutover plan, rollback steps, and a handover document covering upgrades and backups. Ask who performs DNS changes, who holds the server and registrar access, and what happens to Firebase Hosting after cutover. DeployOpen plans, implements, integrates, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope.
What hidden costs appear in a Firebase Hosting exit?
The most common hidden costs are routing rules, DNS and certificate work, and functions that the static site depended on. Firebase Hosting rewrites to Cloud Functions or Cloud Run need a new target, and those functions may themselves be moving off Firebase, so review them with the function migration plan. Certificate renewal and DNS TTL changes need a planned window, and mistakes in them cause visible outages. Sites that use Firebase Authentication or Firestore need those services moved too, which is a separate project. Ask your partner to list each dependency that the static site touches so none is missed.
How DeployOpen scopes and delivers a Firebase Hosting replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Firebase Hosting move, that means the hosting platform, domains, certificates and rewrites are agreed in writing before work starts, then delivered in your cloud account or data center.
How we scope
- Inventory every Firebase Hosting site, target, custom domain and rewrite rule in the current project.
- Agree which sites move to Coolify or Dokploy, and which move to Appwrite Sites, in a written fixed scope.
- Confirm the servers, DNS provider, certificate approach and backup destination you will provide.
How we build
- Set up the chosen platform on your servers, following its installation requirements and resource minimums.
- Rebuild redirects, rewrites to functions and headers, then test each route against the current Firebase behavior.
- Configure custom domains and TLS, and check certificate renewal and HTTP to HTTPS redirects.
How we hand over
- Document the deployment pipeline, server layout, proxy configuration and DNS records used for each site.
- Provide a cutover and rollback runbook, including the DNS change order and the retained Firebase configuration.
- Walk your operators through deploys, certificate checks, backups and restores on the platform you chose.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan platform upgrades on your schedule, testing each release against your redirects and domains first.
- Ask any provider for a written quote that lists scope, deliverables and who maintains each component.
