DOCS-1: Init document work
This commit is contained in:
Blake Ridgway
160
content/privacy/arcline-check-walkthrough.md
Normal file
160
content/privacy/arcline-check-walkthrough.md
Normal file
@@ -0,0 +1,160 @@
|
||||
---
|
||||
title: "How to Check if Your Host is Self-Hosted"
|
||||
description: "Use arcline-check to detect whether a website is truly self-hosted or routed through a CDN/cloud provider."
|
||||
section: privacy
|
||||
order: 2
|
||||
---
|
||||
|
||||
# How to Check if Your Host is Self-Hosted
|
||||
|
||||
The `arcline-check` tool tells you whether a domain is truly self-hosted or routing through Cloudflare, Fastly, AWS CloudFront, or another CDN/cloud provider.
|
||||
|
||||
---
|
||||
|
||||
## What arcline-check does
|
||||
|
||||
When you run `arcline-check example.com`, it:
|
||||
|
||||
1. Resolves the domain to its IP address
|
||||
2. Performs a reverse DNS lookup (PTR record)
|
||||
3. Looks up the ASN (Autonomous System Number) and organization
|
||||
4. Checks whether the IP falls within known CDN/cloud provider CIDR ranges
|
||||
5. Inspects HTTP response headers for CDN signatures (CF-Ray, X-Served-By, etc.)
|
||||
6. Produces a color-coded terminal report
|
||||
|
||||
This is especially useful for:
|
||||
- Evaluating potential hosting providers during migration
|
||||
- Verifying a host's claims about being "self-hosted"
|
||||
- Understanding your own site's infrastructure
|
||||
|
||||
---
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
# Download the latest binary
|
||||
wget https://git.arcline.it/arcline/arcline-check/releases/latest/download/arcline-check-linux-amd64
|
||||
|
||||
# Make it executable
|
||||
chmod +x arcline-check-linux-amd64
|
||||
|
||||
# Move to your PATH
|
||||
sudo mv arcline-check-linux-amd64 /usr/local/bin/arcline-check
|
||||
```
|
||||
|
||||
Or build from source:
|
||||
|
||||
```bash
|
||||
git clone https://git.arcline.it/arcline/arcline-check.git
|
||||
cd arcline-check
|
||||
go build -o arcline-check .
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Basic usage
|
||||
|
||||
```bash
|
||||
arcline-check arcline.it
|
||||
```
|
||||
|
||||
Example output:
|
||||
|
||||
```
|
||||
domain arcline.it
|
||||
resolved 203.0.113.42
|
||||
rdns server1.arclineit.com
|
||||
asn AS64496 Example ISP
|
||||
org Example ISP LLC
|
||||
|
||||
[OK] not behind a known CDN
|
||||
[OK] no Cloudflare headers detected
|
||||
[OK] IP not in AWS/GCP/Azure ranges
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Checking a site behind Cloudflare
|
||||
|
||||
```bash
|
||||
arcline-check example-cloudflare-site.com
|
||||
```
|
||||
|
||||
Example output:
|
||||
|
||||
```
|
||||
domain example-cloudflare-site.com
|
||||
resolved 104.16.42.42
|
||||
rdns 104.16.42.42 (no PTR)
|
||||
asn AS13335 Cloudflare, Inc.
|
||||
org Cloudflare
|
||||
|
||||
[FAIL] behind Cloudflare (CDN)
|
||||
[FAIL] CF-Ray header detected
|
||||
[FAIL] IP in Cloudflare CIDR range
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## JSON output for scripting
|
||||
|
||||
```bash
|
||||
arcline-check example.com --json
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"domain": "example.com",
|
||||
"ip": "203.0.113.42",
|
||||
"rdns": "server1.arclineit.com",
|
||||
"asn": "AS64496",
|
||||
"org": "Example ISP LLC",
|
||||
"cdn_detected": false,
|
||||
"headers": {
|
||||
"server": "nginx/1.24.0"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Watch mode for DNS migration monitoring
|
||||
|
||||
During a DNS migration, use `--watch` to see when propagation completes:
|
||||
|
||||
```bash
|
||||
arcline-check example.com --watch 30
|
||||
```
|
||||
|
||||
This re-checks every 30 seconds. When the IP changes from the old provider to the new one, the output updates in place.
|
||||
|
||||
---
|
||||
|
||||
## Interpreting the results
|
||||
|
||||
| Indicator | What it means |
|
||||
|-----------|---------------|
|
||||
| **IP in Cloudflare range** | The site is behind Cloudflare's proxy (orange cloud) |
|
||||
| **CF-Ray header** | Cloudflare is terminating the connection |
|
||||
| **IP in AWS/GCP/Azure range** | The server is a cloud VM, not self-hosted hardware |
|
||||
| **IP in a residential/business ISP range** | Likely self-hosted (on-premises or colocated) |
|
||||
| **PTR matches domain** | Good operational practice — the host configured rDNS |
|
||||
| **No CDN detected** | Traffic goes directly to the origin server |
|
||||
|
||||
---
|
||||
|
||||
## Limitations
|
||||
|
||||
- A CDN-detected result doesn't always mean bad hosting — some providers use CDNs for legitimate DDoS protection
|
||||
- Arcline doesn't use any CDN by default, but customers are free to add one if they choose
|
||||
- The tool can't detect every possible CDN or proxy — new providers are added regularly
|
||||
- If a site uses Cloudflare spectrum or TCP tunnels, it may appear self-hosted even though Cloudflare is involved
|
||||
|
||||
---
|
||||
|
||||
## What's next
|
||||
|
||||
- [Self-hosting without a CDN: performance tips](/privacy/self-hosting-performance/)
|
||||
- [Why you shouldn't put Cloudflare in front of everything](/privacy/why-not-cloudflare/)
|
||||
- [What SPF, DKIM, and DMARC actually do](/privacy/spf-dkim-dmarc/)
|
||||
|
||||
221
content/privacy/self-hosting-performance.md
Normal file
221
content/privacy/self-hosting-performance.md
Normal file
@@ -0,0 +1,221 @@
|
||||
---
|
||||
title: "Self-Hosting Without a CDN: Performance Tips"
|
||||
description: "How to make your self-hosted site fast without relying on Cloudflare or other CDNs."
|
||||
section: privacy
|
||||
order: 3
|
||||
---
|
||||
|
||||
# Self-Hosting Without a CDN: Performance Tips
|
||||
|
||||
A common objection to self-hosting is "but it won't be fast without a CDN." That's not true for most sites. With proper configuration, a well-tuned Nginx server on a decent VPS will load pages in under 200ms for visitors on the same continent — more than fast enough for a great user experience.
|
||||
|
||||
---
|
||||
|
||||
## Tip 1 — Enable HTTP/2 and HTTP/3
|
||||
|
||||
HTTP/2 multiplexes requests over a single connection. HTTP/3 (QUIC) reduces latency even further.
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 443 ssl http2;
|
||||
listen [::]:443 ssl http2;
|
||||
# HTTP/3 requires Nginx 1.25+ with quic support
|
||||
listen 443 quic reuseport;
|
||||
}
|
||||
```
|
||||
|
||||
Check that HTTP/2 is active by looking at the Chrome DevTools → Network tab — your requests should show `h2` as the protocol.
|
||||
|
||||
---
|
||||
|
||||
## Tip 2 — Aggressive static file caching
|
||||
|
||||
Serve static assets with long cache lifetimes and immutable headers so browsers never re-request them:
|
||||
|
||||
```nginx
|
||||
location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|woff2?)$ {
|
||||
expires 1y;
|
||||
add_header Cache-Control "public, immutable";
|
||||
access_log off;
|
||||
}
|
||||
```
|
||||
|
||||
With immutable caching, the browser will never check if the file has changed until the user force-reloads.
|
||||
|
||||
---
|
||||
|
||||
## Tip 3 — Enable Gzip compression
|
||||
|
||||
Compress text-based responses:
|
||||
|
||||
```nginx
|
||||
gzip on;
|
||||
gzip_vary on;
|
||||
gzip_proxied any;
|
||||
gzip_comp_level 5;
|
||||
gzip_min_length 256;
|
||||
gzip_types
|
||||
text/plain
|
||||
text/css
|
||||
text/javascript
|
||||
application/javascript
|
||||
application/json
|
||||
application/xml
|
||||
image/svg+xml;
|
||||
```
|
||||
|
||||
This can reduce HTML, CSS, and JS payloads by 60–80%.
|
||||
|
||||
---
|
||||
|
||||
## Tip 4 — Use a PHP opcode cache
|
||||
|
||||
For WordPress and other PHP sites, enable OPcache:
|
||||
|
||||
```ini
|
||||
; /etc/php/8.3/cli/conf.d/10-opcache.ini
|
||||
opcache.enable=1
|
||||
opcache.memory_consumption=128
|
||||
opcache.max_accelerated_files=10000
|
||||
opcache.revalidate_freq=120
|
||||
```
|
||||
|
||||
This keeps compiled PHP scripts in memory, avoiding recompilation on every request.
|
||||
|
||||
---
|
||||
|
||||
## Tip 5 — Install a WordPress caching plugin
|
||||
|
||||
For WordPress sites, use a caching plugin that generates static HTML:
|
||||
|
||||
- **WP Super Cache** or **W3 Total Cache**: Generate static HTML files served directly by Nginx
|
||||
- **LiteSpeed Cache**: If you're running LiteSpeed (LSAPI mode)
|
||||
|
||||
See our [W3 Total Cache Configuration](/wordpress/w3-total-cache/) guide for detailed setup instructions without a CDN.
|
||||
|
||||
---
|
||||
|
||||
## Tip 6 — Tune Nginx worker settings
|
||||
|
||||
```nginx
|
||||
worker_processes auto;
|
||||
worker_rlimit_nofile 65535;
|
||||
|
||||
events {
|
||||
worker_connections 4096;
|
||||
use epoll;
|
||||
multi_accept on;
|
||||
}
|
||||
```
|
||||
|
||||
`auto` sets the worker count to the number of CPU cores. `worker_connections 4096` allows each worker to handle 4,000 concurrent connections.
|
||||
|
||||
---
|
||||
|
||||
## Tip 7 — Serve images efficiently
|
||||
|
||||
- **Use WebP** instead of JPEG/PNG (30% smaller). Convert with `cwebp`:
|
||||
```bash
|
||||
sudo apt install webp -y
|
||||
cwebp -q 80 input.jpg -o output.webp
|
||||
```
|
||||
- **Use responsive images** with srcset so mobile devices don't download desktop-sized images
|
||||
- **Lazy-load below-the-fold images** with `loading="lazy"` attribute:
|
||||
```html
|
||||
<img src="photo.jpg" loading="lazy" alt="...">
|
||||
```
|
||||
- **Compress images** with a tool like ImageMagick or optipng before uploading
|
||||
|
||||
---
|
||||
|
||||
## Tip 8 — Optimize your database
|
||||
|
||||
For MySQL/MariaDB:
|
||||
- Enable query cache (MySQL 5.7 and earlier)
|
||||
- Run `mysqlcheck -o --all-databases` weekly
|
||||
- Remove unused plugins and post revisions in WordPress
|
||||
- Use an index on frequently queried columns
|
||||
|
||||
```sql
|
||||
-- Clean up WordPress post revisions
|
||||
DELETE FROM wp_posts WHERE post_type = 'revision';
|
||||
|
||||
-- Optimize tables
|
||||
OPTIMIZE TABLE wp_posts, wp_postmeta;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Tip 9 — Set proper buffer sizes
|
||||
|
||||
```nginx
|
||||
client_body_buffer_size 128k;
|
||||
client_max_body_size 50m;
|
||||
client_header_buffer_size 1k;
|
||||
large_client_header_buffers 4 8k;
|
||||
output_buffers 32 32k;
|
||||
postpone_output 1460;
|
||||
```
|
||||
|
||||
These settings prevent Nginx from buffering more data than necessary per connection.
|
||||
|
||||
---
|
||||
|
||||
## Tip 10 — Choose a geographically close VPS location
|
||||
|
||||
Arcline's data center location matters. A VPS in Dallas will serve US visitors faster than one in Frankfurt. For international audiences, consider:
|
||||
|
||||
- One VPS in the US + one in Europe with a simple round-robin DNS
|
||||
- Or just accept slightly higher latency for overseas visitors — a 200ms response time is still perfectly usable
|
||||
|
||||
---
|
||||
|
||||
## Benchmarking your setup
|
||||
|
||||
After making these changes, test your performance:
|
||||
|
||||
```bash
|
||||
# Install siege for load testing
|
||||
sudo apt install siege -y
|
||||
siege -c 50 -t 60s https://example.com
|
||||
|
||||
# Or use curl to measure response time
|
||||
curl -w "@curl-format.txt" -o /dev/null -s https://example.com
|
||||
```
|
||||
|
||||
Create a format file (`curl-format.txt`):
|
||||
|
||||
```
|
||||
time_namelookup: %{time_namelookup}s
|
||||
time_connect: %{time_connect}s
|
||||
time_appconnect: %{time_appconnect}s
|
||||
time_redirect: %{time_redirect}s
|
||||
time_pretransfer: %{time_pretransfer}s
|
||||
time_starttransfer: %{time_starttransfer}s
|
||||
----------
|
||||
time_total: %{time_total}s
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Real-world results
|
||||
|
||||
A typical Arcline VPS running WordPress with:
|
||||
- Nginx + PHP 8.3 FPM
|
||||
- OPcache enabled
|
||||
- W3 Total Cache (page cache + database cache)
|
||||
- WebP images
|
||||
- Gzip compression
|
||||
|
||||
Will serve pages in **150–300ms** to US visitors and handle **500+ concurrent users** on a $15/mo plan.
|
||||
|
||||
You don't need Cloudflare to be fast. You need a well-configured server.
|
||||
|
||||
---
|
||||
|
||||
## What's next
|
||||
|
||||
- [What SPF, DKIM, and DMARC actually do](/privacy/spf-dkim-dmarc/)
|
||||
- [Why you shouldn't put Cloudflare in front of everything](/privacy/why-not-cloudflare/)
|
||||
- [How to check if a host is self-hosted](/privacy/arcline-check-walkthrough/)
|
||||
|
||||
139
content/privacy/spf-dkim-dmarc.md
Normal file
139
content/privacy/spf-dkim-dmarc.md
Normal file
@@ -0,0 +1,139 @@
|
||||
---
|
||||
title: "What SPF, DKIM, and DMARC Actually Do"
|
||||
description: "An explanation of email authentication standards and how to set them up on Arcline."
|
||||
section: privacy
|
||||
order: 4
|
||||
---
|
||||
|
||||
# What SPF, DKIM, and DMARC Actually Do
|
||||
|
||||
Email authentication standards (SPF, DKIM, DMARC) prevent spammers from sending email that looks like it comes from your domain. Without them, your outgoing email is more likely to land in spam folders — or worse, be used to impersonate you.
|
||||
|
||||
---
|
||||
|
||||
## SPF — Sender Policy Framework
|
||||
|
||||
**What it does**: SPF publishes a list of IP addresses that are authorized to send email for your domain.
|
||||
|
||||
**How it works**:
|
||||
1. A receiving mail server receives a message claiming to be from `@yourdomain.com`
|
||||
2. The receiving server looks up your SPF record at `yourdomain.com`
|
||||
3. If the sending IP is in the SPF record, the message passes. If not, it's subject to the server's spam policy.
|
||||
|
||||
**An SPF record looks like**:
|
||||
|
||||
```
|
||||
v=spf1 mx ip4:203.0.113.42 ~all
|
||||
```
|
||||
|
||||
This means: "Allow mail from your MX servers and from IP 203.0.113.42. Soft-fail everything else."
|
||||
|
||||
**Setting it up on Arcline**:
|
||||
|
||||
In your Arcline cPanel, go to **Domains → Zone Editor** and add a TXT record:
|
||||
|
||||
| Type | Name | Value |
|
||||
|------|------|-------|
|
||||
| TXT | `@` | `v=spf1 mx include:arclineit.com ~all` |
|
||||
|
||||
The `include:arclineit.com` will pull in Arcline's sending IPs automatically.
|
||||
|
||||
---
|
||||
|
||||
## DKIM — DomainKeys Identified Mail
|
||||
|
||||
**What it does**: DKIM signs your outgoing email with a cryptographic signature. The receiving server verifies the signature by looking up your public key in DNS.
|
||||
|
||||
**How it works**:
|
||||
1. Arcline's mail server signs your outgoing message with a private key
|
||||
2. The receiving server looks up your public DKIM key at `selector._domainkey.yourdomain.com`
|
||||
3. It decrypts the signature and verifies the message wasn't tampered with in transit
|
||||
|
||||
**Setting it up on Arcline**:
|
||||
|
||||
Arcline cPanel automatically generates DKIM keys. To verify they're set up:
|
||||
|
||||
1. cPanel → **Email → Email Deliverability**
|
||||
2. Find your domain and click **Manage**
|
||||
3. You should see a green status for DKIM
|
||||
|
||||
The DNS record is automatically added. It looks like:
|
||||
|
||||
| Type | Name | Value |
|
||||
|------|------|-------|
|
||||
| TXT | `arcline._domainkey` | `v=DKIM1; h=sha256; p=MIGfMA0GCSqGSIb4DQEBAQUAA4GNADCBiQKBgQ...` |
|
||||
|
||||
---
|
||||
|
||||
## DMARC — Domain-based Message Authentication, Reporting & Conformance
|
||||
|
||||
**What it does**: DMARC tells receiving servers what to do when a message fails SPF or DKIM checks. It also provides reports so you can see who's sending email on your behalf.
|
||||
|
||||
**How it works**:
|
||||
1. A message arrives claiming to be from your domain
|
||||
2. The receiving server checks SPF and DKIM
|
||||
3. If both pass, the DMARC policy doesn't matter
|
||||
4. If one or both fail, the server follows your DMARC policy:
|
||||
- `none` — Take no action (just report)
|
||||
- `quarantine` — Mark as spam
|
||||
- `reject` — Reject the message outright
|
||||
|
||||
**Setting it up on Arcline**:
|
||||
|
||||
Start with `p=none` to see who's sending email for your domain without blocking anything. After a few weeks, review the reports and tighten to `p=quarantine`. After confirming all legitimate email is authenticated, move to `p=reject`.
|
||||
|
||||
| Type | Name | Value |
|
||||
|------|------|-------|
|
||||
| TXT | `_dmarc` | `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com` |
|
||||
|
||||
The `rua` field specifies where you want to receive aggregate DMARC reports. Tools like [dmarcian.com](https://dmarcian.com) or [Postmark's DMARC tool](https://dmarc.postmarkapp.com) can help you parse them.
|
||||
|
||||
---
|
||||
|
||||
## All three records together
|
||||
|
||||
For `yourdomain.com`, your DNS zone should have these TXT records:
|
||||
|
||||
```
|
||||
yourdomain.com. TXT "v=spf1 mx include:arclineit.com ~all"
|
||||
arcline._domainkey.yourdomain.com. TXT "v=DKIM1; h=sha256; p=..."
|
||||
_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Testing your setup
|
||||
|
||||
Use one of these free tools to verify everything is working:
|
||||
|
||||
```bash
|
||||
# Command line
|
||||
dig TXT yourdomain.com +short
|
||||
dig TXT arcline._domainkey.yourdomain.com +short
|
||||
dig TXT _dmarc.yourdomain.com +short
|
||||
```
|
||||
|
||||
Or visit:
|
||||
- [MXToolbox](https://mxtoolbox.com/diagnostic.aspx) — enter your domain
|
||||
- [Mail-Tester](https://www.mail-tester.com) — send a test email to the address shown
|
||||
|
||||
---
|
||||
|
||||
## Common issues
|
||||
|
||||
| Symptom | Likely cause |
|
||||
|---------|--------------|
|
||||
| SPF passes but emails still go to spam | Missing or misconfigured DKIM |
|
||||
| DKIM passes but emails go to spam | Missing DMARC policy |
|
||||
| DMARC reports show IPs you don't recognize | Someone is spoofing your domain — set `p=reject` |
|
||||
| DMARC reports show a legitimate service failing | Add the service's IPs to your SPF record |
|
||||
| Automated reports from third-party services | Their infrastructure needs to be included in your SPF record — contact them for their SPF include |
|
||||
|
||||
---
|
||||
|
||||
## What's next
|
||||
|
||||
- [Why you shouldn't put Cloudflare in front of everything](/privacy/why-not-cloudflare/)
|
||||
- [Self-hosting without a CDN: performance tips](/privacy/self-hosting-performance/)
|
||||
- [Set up email on Arcline](/getting-started/email-setup/)
|
||||
|
||||
101
content/privacy/why-not-cloudflare.md
Normal file
101
content/privacy/why-not-cloudflare.md
Normal file
@@ -0,0 +1,101 @@
|
||||
---
|
||||
title: "Why You Shouldn't Put Cloudflare in Front of Everything"
|
||||
description: "The hidden costs of relying on Cloudflare: privacy concerns, vendor lock-in, and single points of failure."
|
||||
section: privacy
|
||||
order: 1
|
||||
---
|
||||
|
||||
# Why You Shouldn't Put Cloudflare in Front of Everything
|
||||
|
||||
Cloudflare is popular — it's fast, free, and easy to set up. But the convenience comes with tradeoffs that matter, especially for a hosting provider that prides itself on self-hosting and privacy.
|
||||
|
||||
---
|
||||
|
||||
## The single point of failure
|
||||
|
||||
When you put Cloudflare in front of your origin server, Cloudflare becomes your infrastructure. If Cloudflare has an outage (and they've had several), your site goes down even if your server is perfectly healthy.
|
||||
|
||||
In 2022, a Cloudflare global outage took down 20% of the internet's top million sites. Customers couldn't access their own servers because DNS wasn't resolving. If you self-host on Arcline, your DNS and traffic should be under your control.
|
||||
|
||||
---
|
||||
|
||||
## Cloudflare terminates TLS
|
||||
|
||||
This is the most important point for privacy-conscious site owners. When you use Cloudflare's proxy (orange cloud), Cloudflare terminates the TLS connection. Traffic between Cloudflare and your origin server travels in plaintext unless you set up a separate origin certificate.
|
||||
|
||||
This means Cloudflare can:
|
||||
- Read all traffic passing through their network
|
||||
- Inject JavaScript into your pages (which they do for features like Rocket Loader and bot management)
|
||||
- Modify your HTML, images, and CSS
|
||||
- See every visitor's IP address, browser, and behavior
|
||||
|
||||
If you're hosting anything sensitive — even a personal blog — you're trusting Cloudflare with all of it.
|
||||
|
||||
---
|
||||
|
||||
## Vendor lock-in
|
||||
|
||||
Once you're deep in the Cloudflare ecosystem, leaving becomes painful:
|
||||
|
||||
- **DNS records**: You manage DNS inside Cloudflare, not on your authoritative nameservers
|
||||
- **Page Rules**: Caching, redirects, and rewriting rules are configured in Cloudflare's interface
|
||||
- **SSL certificates**: Cloudflare issues and manages certs for your domains
|
||||
- **Workers**: Serverless functions that only run on Cloudflare's network
|
||||
- **Analytics**: Historical data lives in Cloudflare, not on your servers
|
||||
- **Email routing**: Cloudflare's email forwarding is a sticky dependency
|
||||
|
||||
Each of these features makes Cloudflare harder to walk away from. The free tier becomes a golden handcuff.
|
||||
|
||||
---
|
||||
|
||||
## Privacy implications
|
||||
|
||||
Cloudflare sits between your visitors and your server. This means:
|
||||
|
||||
- Every visitor's IP address is visible to Cloudflare (they claim not to sell it, but you're still sharing it)
|
||||
- Cloudflare can build behavioral profiles across the millions of sites on their network
|
||||
- Visitors on Cloudflare see "This site is powered by Cloudflare" banners and CAPTCHAs
|
||||
- The more sites that use Cloudflare, the more centralized the internet becomes
|
||||
|
||||
For a hosting company that markets itself on privacy and independence, directing customers to Cloudflare undermines the entire value proposition.
|
||||
|
||||
---
|
||||
|
||||
## When Cloudflare makes sense
|
||||
|
||||
There are legitimate use cases:
|
||||
|
||||
- **DDoS protection**: Cloudflare's network can absorb attacks that would overwhelm a single server
|
||||
- **Global CDN**: If most of your visitors are on another continent, Cloudflare's edge cache speeds up delivery
|
||||
- **API protection**: Rate limiting and bot detection at the edge
|
||||
|
||||
But these should be deliberate choices for specific problems, not a default for every site.
|
||||
|
||||
---
|
||||
|
||||
## The Arcline approach
|
||||
|
||||
Arcline is built on the principle that you should control your own infrastructure:
|
||||
|
||||
- DNS is hosted on Arcline's own authoritative nameservers (NSD)
|
||||
- TLS terminates at your server — no third party sees your traffic
|
||||
- Static sites are served directly by Nginx, without an intermediary
|
||||
- Monitoring and analytics are self-hosted (Prometheus + arcline-uptime)
|
||||
|
||||
This means you don't get Cloudflare's global CDN or DDoS scrubbing by default. What you get is:
|
||||
|
||||
- Full control over your traffic
|
||||
- No third party reading your visitors' data
|
||||
- No vendor lock-in
|
||||
- Complete architectural flexibility
|
||||
|
||||
For most small to medium sites, a single VPS with proper Nginx tuning, a good caching strategy, and fail2ban for security is more than adequate. See our [Self-Hosting Performance Tips](/privacy/self-hosting-performance/) guide for making the most of it.
|
||||
|
||||
---
|
||||
|
||||
## What's next
|
||||
|
||||
- [How to check if a host is self-hosted](/privacy/arcline-check-walkthrough/) — use arcline-check
|
||||
- [Self-hosting without a CDN: performance tips](/privacy/self-hosting-performance/)
|
||||
- [What SPF, DKIM, and DMARC actually do](/privacy/spf-dkim-dmarc/)
|
||||
|
||||
Reference in New Issue
Block a user