Connect customer domains with the infrastructure that fits your SaaS
Approximated and Cloudflare for SaaS both help applications serve customer-owned domains over HTTPS. Approximated is a strong fit when you want a dedicated proxy cluster and IPv4 address, an embeddable DNS setup flow, or a choice of managed and self-hosted deployments. Cloudflare for SaaS is a strong fit when you want custom hostnames on Cloudflare’s network and already use its security and performance services. See how Approximated works and Cloudflare’s product overview.
The useful comparison starts with your customers’ DNS setup, your origin routing, and the infrastructure you want to operate. Here is how the products differ.
Compare the domain connection workflow
| Requirement | Approximated | Cloudflare for SaaS |
|---|---|---|
| Customer domains and HTTPS | A virtual host maps a customer hostname to your application; the proxy cluster manages its TLS certificate. | Custom hostnames connect customer domains to your SaaS service with managed certificates. |
| Different applications or origins | Configure a target address for each virtual host. | Use a fallback origin, with custom origins for hostnames that need a different target. |
| Apex domain using an A record | Point the customer’s apex A record at your cluster’s dedicated IPv4 address. | Cloudflare’s Apex Proxying product supplies an IP-based path; see the apex section below. |
| Where the proxy runs | Approximated cloud, hybrid self-hosted, or full self-hosted. | Cloudflare’s managed network. |
Sources: Approximated architecture, virtual hosts, deployment options, Cloudflare overview, and custom origins.
Apex domains: decide what DNS change your customers can make
For a customer connecting example.com, Approximated lets you provide an A record pointing to your cluster’s dedicated IPv4 address. That address belongs to the cluster and can serve its configured customer domains. A dedicated cluster IP does not mean a separate IP for every customer domain. Approximated proxy clusters.
Cloudflare’s usual SaaS onboarding path uses a CNAME. Some DNS providers support apex flattening or equivalent features. For customers who need a conventional apex A record, Cloudflare documents Apex Proxying, including IP prefixes supplied by Cloudflare or brought by the SaaS provider. Its plan matrix lists this as a paid Enterprise add-on. Apex Proxying, plan availability.
Test the DNS providers your customers actually use, including customers whose DNS is already proxied. The required DNS records should be part of your product’s onboarding flow.
Give customers an in-app DNS setup flow
Approximated’s optional widget identifies the DNS provider and presents the records your customer needs to change. It offers an automatic setup option where a supported integration is available and provides manual instructions. Customers can then check whether the requested records are visible in DNS. Explore the DNS setup widget or read the DNS widget documentation and demo.
Your application still manages the domain-to-customer association and checks certificate and application readiness. Showing the correct DNS records is one step in connecting a working custom domain.
Route each domain to the right application
An Approximated virtual host pairs an incoming hostname with a target address. This supports a shared application origin or different targets for different domains. Your application remains responsible for tenant selection and authorization. Virtual Hosts API.
Cloudflare also supports custom origins; different targets are not an Approximated-only capability. Its custom-origin configuration uses a hostname represented by a proxied DNS record in the Cloudflare account. Review origin Host and TLS/SNI behavior against your application’s requirements before migrating. Cloudflare custom-origin requirements.
Match security controls to your application
For domain-specific request decisions, Approximated’s Edge Verify supports rules at the virtual-host level and across a cluster. Evaluate its request checks against the actions your application needs. Edge Verify documentation.
Cloudflare supports security rules for SaaS hostnames, including workflows that select policies through hostname metadata. Availability depends on the rule type and plan: its self-serve plans use the zone’s WAF capabilities, while additional SaaS features have separate entitlements. WAF for SaaS, plan details.
Use a representative tenant policy in your evaluation, such as a protected admin path. Verify which requests it permits and denies, its scope, and how you inspect the result. Feature names alone do not establish equivalent behavior.
Choose how much infrastructure you operate
Approximated Cloud runs the proxy infrastructure for you. Hybrid Self Hosted keeps traffic and certificates on your infrastructure while using Approximated’s cloud API and dashboard. Full Self Hosted provides an independent installation with its own API and dashboard. Compare the scope and features of each deployment before choosing. Self-hosted plans.
This makes Approximated worth evaluating when infrastructure location or operating the proxy yourself is part of the requirement. Your deployment choice should include the operational responsibilities and support arrangement you need.
Monthly costs with the assumptions visible
Approximated Cloud’s published rate is $0.20 per domain per month with a $20 minimum. Domain charges receive a 5-percentage-point discount for every full 1,000 domains, up to 50%. The plan includes 400 GB of monthly bandwidth; additional bandwidth is $0.05 per GB. Approximated pricing.
Cloudflare’s self-serve SaaS plans include 100 hostnames and charge $0.10 for each additional hostname. Cloudflare pricing and plans.
The examples below assume a steady number of domains for a full month. They use USD, exclude taxes and application/origin hosting, and apply Approximated’s published cloud pricing. The final column is Cloudflare’s hostname charge only; add any applicable zone plan and paid services when estimating your Cloudflare bill.
| Domains | Bandwidth/month | APX domain charge | APX bandwidth charge | APX modeled total | CF hostname charge only |
|---|---|---|---|---|---|
| 100 | 100 GB | $20 | $0 | $20 | $0 |
| 1,000 | 1,000 GB | $190 | $30 | $220 | $90 |
| 10,000 | 10,000 GB | $1,000 | $480 | $1,480 | $990 |
For example, 1,000 domains receive a 5% domain discount: 1,000 × $0.20 × 0.95 = $190. At 1,000 GB, the additional 600 GB costs $30, for an Approximated total of $220.
Cloudflare has the lower hostname charge in these examples. Evaluate Approximated for the dedicated cluster/IP, DNS onboarding workflow, and deployment options you need, and compare the complete configurations you would actually buy.
A practical migration from Cloudflare for SaaS
- Inventory the current setup. Record each customer hostname, tenant, origin, DNS target, certificate requirements, and any request or security rules. Identify apex records, customer-proxied DNS, redirects, and applications that depend on particular Host headers.
- Prepare the Approximated configuration. Create the cluster and matching virtual hosts. Connect the domain lifecycle to your application, including status checks and deletion. Keep the existing service available while preparing the new route.
- Prove the application path with a domain you control. Verify HTTPS, the correct tenant and origin, login/session behavior, redirects, and any application-specific traffic such as WebSockets. Confirm how certificates become ready for the planned cutover.
- Move a small customer cohort. Give each customer the precise DNS change. Plan around their existing TTLs and validation requirements. Keep the previous DNS values and routing configuration available for recovery.
- Verify the customer-facing result. Check DNS, certificate status, and an actual HTTPS request separately. Monitor application errors and support reports before moving the next cohort. Restoring DNS is subject to caching; treat recovery as a tested procedure.
- Retire the old configuration after the transition. Remove old custom hostnames only after the customer is operating through the new path and the recovery window has passed. Include abandoned or pending hostnames in the cleanup inventory; Cloudflare documents how hostname status affects billing. Cloudflare quotas and billing.
This is a migration outline, not a guarantee of interruption-free cutover. The correct certificate-validation and DNS sequence depends on the existing setup. Start with Approximated’s API documentation and your application’s integration guide.
Questions before you choose
- Can I keep my current application hosting?
- Approximated sends configured custom-domain traffic to the target address you provide. Verify that the origin accepts the expected requests and host behavior. See the guides for Next.js, Laravel, Rails, and Phoenix.
- Do customers have to transfer their domains?
- Connecting a domain to Approximated uses DNS records at the customer’s DNS provider. Buying or transferring the domain is a separate process. The widget demo shows the setup experience.
- Does creating a domain mean it is ready for customer traffic?
- No. Domain configuration, DNS, certificate readiness, and a successful application request are separate checks. Build those states into your onboarding flow. Product lifecycle.
- How should I evaluate the two services?
- Choose a small set of representative domains, including an apex domain and a domain with a different origin. Test onboarding, HTTPS, a tenant policy, and recovery. Then compare the costs and operating responsibilities for that configuration.