New Chat
/
auto-free-cloud
/
Select a Prompt
How do I set up a systemd service file for Caddy that safely passes DNS API tokens?
auto-free-cloud
Thought for 13s
To set up a systemd service for Caddy that safely handles DNS API tokens (like for Let's Encrypt), you must avoid passing the token as a command-line argument. Command-line arguments are easily visible via ps aux or shell history.
Instead, you should use Environment Files (.env) to securely inject the token into the process environment.
Here is the step-by-step guide to doing this safely.

Ensure you have Caddy installed and a caddy user. The official Caddy packages usually handle this automatically.

We will store the environment file and Caddy configuration in a dedicated, secure directory.
bash
sudo mkdir -p /etc/caddy

This is the most critical step for security. Never put the token in the systemd unit file or the Caddy config file directly.
Create a file named /etc/caddy/caddy.env. You can use your editor of choice (e.g., nano, vim).
bash
sudo nano /etc/caddy/caddy.env
Replace the placeholder with your actual DNS API token:
text

 CLOUDFLARE_API_TOKEN=abcdef0123456789ghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
Set strict permissions: This file should be readable by the caddy user but not writable (to prevent the user from modifying it accidentally), and not readable by the general public.
bash

 sudo chown root:caddy /etc/caddy/caddy.env
sudo chmod 640 /etc/caddy/caddy.env

Create your Caddyfile at /etc/caddy/Caddyfile. Here is a standard example that uses the token for DNS validation (ACME).
bash
sudo nano /etc/caddy/Caddyfile
Example Caddyfile:
text
{
# Use the environment variable for the DNS API token
# Syntax: dns {ENV_VAR_NAME}      dns cloudflare {CLOUDFLARE_API_TOKEN}

    
# Optional: email for Let's Encrypt
admin your-email@example.com
}

 
example.com, www.example.com {
root /var/www/caddy
file_server
}
Note: Replace * cloudflare and {$CLOUDFLARE_API_TOKEN} with the provider you are using (e.g., digitalocean , route53 ). The curly braces {} tell Caddy to look for the environment variable.

Create the service file. Systemd allows us to EnvironmentFile= which reads the .env file into the service's environment securely.
bash
sudo nano /etc/systemd/system/caddy.service
Paste the following content:
ini
[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Wants=network-online.target

 
[Service]
Type=notify
User=caddy
Group=caddy
# Point to the secure environment file
EnvironmentFile=/etc/caddy/caddy.env
# Path to the Caddyfile
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
Restart=on-failure
RestartSec=5
TimeoutStopSec=5
# KillMode=mixed preserves caddy processes on restart
KillMode=mixed

 
[Install]
WantedBy=multi-user.target

Before starting the service, it is good practice to check if the user and file permissions are correct.

Start the service and enable it to run on boot.
bash
sudo systemctl start caddy
sudo systemctl enable caddy

Check the status to ensure it loaded the environment variables and the DNS token is available in the process context.
bash
sudo journalctl -u caddy -f

If something else is already listening on port 80 or 443 (for example, another web server like Nginx or Apache), Caddy will fail to start with an error like:
text
Failed to bind to 0.0.0.0:80: Address already in use
Solution: Before starting the service, verify the ports are free:
bash
sudo ss -tlnp | grep ':80|:443'
If you see output indicating a conflict, stop the conflicting service or change Caddy's listening ports in its configuration.

Because you are using a DNS API token (for Let's Encrypt), Caddy will automatically request and renew certificates. The systemd service handles this seamlessly—no extra steps are required beyond having a valid Caddyfile pointing to your DNS provider.
However, make sure your system has a way to receive the renewal emails (if using SMTP) or ensure the DNS provider supports automatic renewal. Most modern DNS providers (Cloudflare, Route53, etc.) handle this automatically.

Table
SettingDefault BehaviorHTTP ListenerPort 80 (redirects to HTTPS) HTTPS ListenerPort 443 (uses DNS token for ACME) ConfigurationHandled inside /etc/caddy/Caddyfile
Your current systemd setup is correct for this behavior. Just ensure the ports aren't occupied before starting.
Then I will have to shut down my Apache PHP server? Does Caddy do PHP?
auto-free-cloud
Thought for 4s
Short answer:

Caddy includes a built-in PHP handler (no separate php-fpm or Apache .htaccess tricks required for basic PHP). You just need:

 
# RHEL/CentOS/Fedora
sudo dnf install php php-cli php-fpm
4. (Caddy uses php-fpm internally; installing php-fpm is sufficient. php-cli usually comes with it.)
5. Enable PHP in your Caddyfile using the @php directive (or php directive). Example Caddyfile:
6. caddy
7. {
# (Your existing dns line, e.g., dns cloudflare {$CLOUDFLARE_API_TOKEN})
}

 
example.com {
php /path/to/your/php/files  # <-- This line enables PHP for this site
root /var/www/caddy      # <-- Your PHP files go here (e.g., /var/www/caddy/index.php)
file_server                  # Serves static files (HTML, CSS, JS)
}
8. How it works:*php /path/to/your/php/files tells Caddy: "For requests to example.com, if the request is for a .php file under /path/to/your/php/files, run it with PHP; otherwise serve static files." No .htaccess, no Apache phpadmin config needed.
✅ Verification:
Place a simple index.php in /var/www/caddy (e.g., ). Reload the site in a browser → you see "Hello from Caddy PHP!" (works over HTTPS if using Let's Encrypt).

Table
GoalActionWhy?"I want Caddy on the public ports (80/443) for Let's Encrypt" (recommended for production)1. Stop Apache: sudo systemctl stop apache2 (or httpd, check your service name)
2. Start Caddy: sudo systemctl start caddyCaddy binds to 80/443; Apache would conflict. Stopping Apache removes the conflict. Caddy handles PHP via php /path/... in Caddyfile. "I want to test Caddy without touching Apache yet"1. Change Caddy to listen on port 8080 temporarily in Caddyfile:
example.com { php /var/www/caddy; root /var/www/caddy; listen 127.0.0.1:8080 }
2. Start Caddy (sudo systemctl start caddy)
3. Visit http://localhost:8080 in browser to test PHPNo conflict with Apache (Apache still on 80/443). Lets you verify Caddy + PHP works before releasing to production ports. "I want to keep Apache running for now"1. Stop Apache: sudo systemctl stop apache2 (or equivalent)
2. Start Caddy: sudo systemctl start caddy
3. (Later) Stop Caddy if you want to revert, or change Caddy to port 8080 for coexistenceSimplest safe production path: one web server owns port 80/443. You replace Apache with Caddy.
🔍 How to check which service is using port 80/443 (quick command):
bash
sudo ss -tlnp | grep ':80|:443'
Example output:
text
LISTEN 0      128    0.0.0.0:80      0.0.0.0:    users:(("apache2",pid=1234,fd=3))
LISTEN 0      128    0.0.0.0:443     0.0.0.0:*    users:(("apache2",pid=1234,fd=4))
→ Shows Apache is listening. If you see Caddy (caddy, user=caddy) instead, Apache is stopped.

"Yes, if you want Caddy to use the standard public ports (80 for HTTP, 443 for HTTPS – which you need for Let's Encrypt and your DNS API token), you must stop your current Apache server (because both Apache and Caddy cannot listen on the same ports at the same time).
However, Caddy supports PHP natively. You just need to:

Apache will continue serving normally:

Modify your Caddyfile to listen on port 8080 and serve from /var/www/html:
bash
sudo nano /etc/caddy/Caddyfile
Updated Caddyfile:
text
{
# Use the environment variable for the DNS API token
dns cloudflare {$CLOUDFLARE_API_TOKEN}

    
# Optional: email for Let's Encrypt
admin your-email@example.com
}

 
# Test configuration - serve on port 8080
:8080 {
root * /var/www/html
php
file_server
}

 
# Production configuration (commented out for now)
# example.com, www.example.com {
#     root * /var/www/html
#     php
#     file_server
# }

Modify the systemd service to use the test configuration:
bash
sudo nano /etc/systemd/system/caddy.service
Updated service file:
ini
[Unit]
Description=Caddy (Test on port 8080)
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Wants=network-online.target

 
[Service]
Type=notify
User=caddy
Group=caddy
EnvironmentFile=/etc/caddy/caddy.env
# Use the test configuration with port 8080
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
Restart=on-failure
RestartSec=5
TimeoutStopSec=5
KillMode=mixed

 
[Install]
WantedBy=multi-user.target

bash
sudo systemctl daemon-reload
sudo systemctl start caddy
sudo systemctl enable caddy

Check that both Apache and Caddy are listening on their respective ports:
bash

 sudo ss -tlnp | grep ':80|:8080'

 
# You should see something like:
# LISTEN 0      128    0.0.0.0:80      0.0.0.0:    users:(("apache2",pid=1234,fd=3))
# LISTEN 0      128    0.0.0.0:8080     0.0.0.0:    users:(("caddy",pid=5678,fd=4))

Create a test PHP file to verify PHP processing:
bash
sudo nano /var/www/html/test-caddy.php
php

Visit: http://your-server-ip:8080/test-caddy.php

When you're satisfied that Caddy works correctly with your PHP application:

 
example.com, www.example.com {
root * /var/www/html
php
file_server
}
7. Restart Caddy:
8. bash
9. sudo systemctl restart caddy

In a single Caddyfile, you can:

1. Edit your Caddyfile (/etc/caddy/Caddyfile):
Keep your existing site configuration, then add reverse_proxy directives where needed.
text
{
dns cloudflare {$CLOUDFLARE_API_TOKEN}
admin your-email@example.com
}

 
# Your main site (serving /var/www/html) - UNCHANGED
:8080 {
root * /var/www/html
php
file_server
}

 
# Example 1: Proxy a Node.js app running on localhost:3000
# Access via: http://your-server:8080/node-app
:8080/node-app {
reverse_proxy localhost:3000
}

 
# Example 2: Proxy Grafana running on localhost:3001 under /grafana
# Access via: http://your-server:8080/grafana
:8080/grafana {
reverse_proxy localhost:3001
}

 
# Example 3: Proxy multiple services under different subpaths (all on :8080)
:8080 {
# ... your existing site config (root/php/file_server) ...

 
# Proxy /api to a backend API
reverse_proxy /api* localhost:4000

 
# Proxy /admin to a different backend
reverse_proxy /admin* localhost:5000
}
💡 How it works:

 
# Create a test directory and start it on port 3000
mkdir -p /tmp/node-app && echo "Hello from Node.js!" > /tmp/node-app/index.html
http-server /tmp/node-app -p 3000 &
4. Reload Caddy:
5. bash
6. sudo systemctl reload caddy
7. Test in your browser:

Table
ScenarioHow to HandleStill testing on port 8080?Use :8080 in the Caddyfile (as shown above). Backends can be localhost:PORT. Ready for production (ports 80/443)?Change :8080 → example.com, www.example.com (or just :80 for HTTP, then Caddy auto-upgrades to HTTPS via ACME). Backend is on another machine?Replace localhost:3000 → backend.internal:3000 or 10.0.0.5:3000. Need WebSockets (e.g., Socket.io)?Caddy handles this automatically — no extra config needed! Just reverse_proxy. Want load balancing?reverse_proxy /api* { to localhost:4000 localhost:4001 } (Caddy does round-robin by default). Backend needs specific headers?Use header_up or header_down inside reverse_proxy (e.g., header_up Host {host}).

Once you stop Apache and move Caddy to ports 80/443:

 
example.com, www.example.com {
root * /var/www/html
php
file_server

 
# Proxy examples (now on port 443 with auto-HTTPS!)
reverse_proxy /api localhost:4000
reverse_proxy /grafana localhost:3001
}
4. Stop Apache: sudo systemctl stop apache2
5. Restart Caddy: sudo systemctl restart caddy
6. Visit https://example.com → Your site
Visit https://example.com/api → Proxied to your backend (with valid Let's Encrypt cert!)

After adding proxy rules: