Cloudflare DNS Setup for VPS Sites: Auto vs Manual

DNS is where a lot of otherwise good deployments start to feel broken.

The app is installed. The server is healthy. The dashboard is live. But then the domain still does not open, or SSL fails, or the wrong IP is still active because an old record was never replaced.

That is why LarVPS treats DNS as a first-class part of site setup instead of leaving it as an afterthought.

In LarVPS, you usually choose between two DNS paths:

• Auto via Cloudflare
• Manual DNS

Both are valid. The important thing is knowing which one fits the situation and what the dashboard is really trying to tell you.

The short version

Use Auto via Cloudflare when:

• your team already connected Cloudflare at the team level
• the zone is clearly under your control
• you want LarVPS to create or reuse the right record during setup

Use Manual DNS when:

• the domain is managed elsewhere
• another person controls DNS
• you want to review records yourself
• you are dealing with a live production domain and want explicit human confirmation before changing traffic

Why LarVPS uses team-level Cloudflare

Cloudflare integration in LarVPS is a team-level infrastructure capability, not a per-user toy.

That design matters because DNS is usually a shared operational resource:

• agencies manage many client sites
• small teams share one Cloudflare account
• operators need consistent access across sites

If DNS credentials lived per user, the product would become harder to reason about and easier to break.

What “Auto via Cloudflare” actually does

When you choose Auto via Cloudflare, LarVPS does not blindly rewrite the world.

It preflights the requested host and asks:

• is this zone covered by the team’s Cloudflare token?
• does a record already exist?
• if it exists, is it already pointing to the target server?
• if it exists and points elsewhere, should the operator explicitly approve an overwrite?

That is the correct behavior for a professional DNS flow.

The platform should help, but the responsibility for the domain still belongs to the operator.

The three main Auto via Cloudflare outcomes

1. No record exists yet

This is the easiest case.

Example:

• you are creating app.example.com
• Cloudflare zone example.com is connected
• app.example.com does not exist yet

LarVPS can safely say:

“This record will be created automatically during setup.”

That is the ideal Auto via Cloudflare experience.

2. The record already exists and points to the correct IP

This is also safe.

Example:

• www.example.com already exists
• it already points to the server you selected

In that case LarVPS should reuse the record and tell the user clearly that no destructive DNS change is needed.

3. The record exists but points somewhere else

This is the dangerous case.

Example:

• shop.example.com already points to an older VPS
• you are about to create a new site on a different machine

In this case a “helpful” product should not silently replace the record.

It should tell you:

• the hostname already exists
• it currently points to another IP
• changing it may redirect live traffic
• you need to confirm whether to overwrite

That is exactly the kind of moment where the platform should assist, not take ownership away from the operator.

What “Manual DNS” means in practice

Manual DNS is not a second-class option. It is often the right one.

Use it when:

• DNS is managed outside Cloudflare
• another department controls the zone
• the site is part of a live migration
• you want to review the final records yourself

LarVPS should then guide the user with the exact next action instead of just saying “DNS is wrong.”

For a typical root domain setup, that usually means:

• A record for @ to the server IP
• CNAME record for www to the primary domain

If the requested site is a subdomain, it usually means:

• A record for subdomain to the server IP

Why “domain not live yet” is not the same as “site failed”

This is one of the most important ideas for operators to understand.

A site can be provisioned successfully while the domain is still not resolving to the server.

Those are different layers:

• site provisioning
• DNS routing
• SSL issuance

That is why the right product language is:

“Site is ready. SSL is waiting for DNS.”

That phrasing is honest and reduces false panic.

How SSL fits into the DNS story

Most “SSL failed” reports are really DNS timing problems.

If the certificate step runs before the domain resolves correctly, Let’s Encrypt validation can fail even though:

• the server is fine
• the app is fine
• the Nginx config is fine

So the order matters:

1. create the site
2. point DNS correctly
3. wait for propagation
4. issue SSL

When that order is respected, SSL becomes much more predictable.

What about subdomains?

Subdomains are common and should feel normal in the product.

Examples:

• app.example.com
• admin.example.com
• staging.example.com

From a DNS perspective, these are usually simpler than the apex domain because they do not need the same root-domain handling concerns.

In LarVPS, a good Auto via Cloudflare flow for subdomains should tell the user one of the following:

• this subdomain does not exist yet and will be created
• this subdomain already points correctly and will be reused
• this subdomain currently points elsewhere and needs overwrite confirmation

That is the “pro” behavior operators expect.

What about SEO use cases?

DNS decisions and domain decisions overlap, but they are not identical.

A lot of SEO teams buy or manage:

• old domains
• campaign domains
• microsite domains
• brand-protection domains

Those domains usually need one of three outcomes:

• serve the same site
• 301 redirect to the primary domain
• remain under manual control until the operator decides what to do

DNS simply points traffic. It does not decide your content or redirect strategy by itself.

That is why LarVPS now distinguishes domain strategy separately instead of pretending every extra domain is just “another DNS record.”

Common mistakes to avoid

1. Letting the platform overwrite live DNS without review

Automation is useful, but silent DNS takeover is not.

If a record already points elsewhere, that should be explicit.

2. Treating SSL as a site creation step instead of a DNS-dependent step

The app can be ready before the certificate is.

3. Forgetting team ownership of Cloudflare access

Cloudflare connection is a team-level infrastructure resource. Make sure the team token really covers the zones you intend to use.

4. Not knowing which zone the token can manage

A good operator should always know:

• which zones are granted
• which ones are outside scope
• whether a hostname belongs to a manageable zone

5. Creating extra records without a domain strategy

Pointing domains is easy. Knowing whether they should serve content, alias, or redirect is the real decision.

Recommended DNS decision framework

If you want a simple rule set, use this:

Choose Auto via Cloudflare when:

• the zone belongs to your team
• the domain is new or low-risk
• you want the fastest setup path

Choose Manual DNS when:

• the record is already live in production
• another team or client owns DNS
• you want human review before traffic moves

Delay SSL issuance until:

• the domain resolves correctly
• the dashboard can confirm the correct destination

Final takeaway

There is nothing wrong with either Auto via Cloudflare or Manual DNS.

The real goal is clarity:

• who owns the zone
• what record already exists
• whether traffic is about to move
• whether SSL is blocked by DNS or by something deeper

If the platform explains those four things well, DNS stops feeling random and starts feeling operationally safe.