NodeBB

Use this category to share how you run wpfy in the wild.

What to post

• Your server specs (VPS provider, RAM, CPU, region)
• How many sites you host on one VPS
• Your PHP versions and any custom Compose tweaks
• A screenshot of wpfy site list or wpfy debug output (redacted)
• What you use wpfy for (agency fleet, personal sites, client work)

Rules

• No secrets. Redact every password, token, and .env value.
• No client domains unless you have permission to share them.
• Keep it constructive — this is for the community to learn from real deployments.

Template

**Provider:** Vultr / Hetzner / DigitalOcean / other
**Specs:** 2 vCPU, 4 GB RAM, 80 GB disk
**Region:** Amsterdam
**Sites:** N isolated stacks
**PHP:** 8.4 default, one site on 8.2
**Notes:** anything custom worth sharing

Looking forward to seeing your setups.

What's deferred and why. wpfy is beta software — some features are intentionally out of v1 and tracked here so the community knows what's coming and can weigh in.

Post feature requests in this category. Search first to avoid duplicates; upvote existing requests instead of reposting.

Currently deferred (tracked in the project's open questions)

These are documented in the repo's memory and decision log. They are not bugs — they are explicit deferrals pending validation or an architecture decision.

Disposable-VPS validation

The validation harness exists (scripts/vps-release-validation*.sh) but the final disposable-VPS release run is pending. Until it completes, treat wpfy as beta for production.

Traefik Docker socket risk reduction

Traefik reads the Docker socket for container discovery. A socket-proxy adoption decision is open. See Security.

Supply-chain verification depth

How deeply upstream WordPress / WP-CLI artifacts are verified before provisioning is an open question. Currently pull-only.

Non-root / read-only filesystem compatibility

PHP-FPM images currently run as root (USER www-data deferred — needs a volume-ownership strategy). Explicit non-root and read-only-filesystem compatibility is pending.

External scanner runs

testssl.sh and nuclei have not been run against a live wpfy host. Hardening probes (Nginx, security headers, ACME, reboot persistence) passed on the last validation VPS.

How to request a feature

1. Search this category first.
2. If no match, start a new topic with:
   • The problem you're trying to solve (not just the solution)
   • The wpfy command or workflow you wish existed
   • Whether you'd be willing to test a PR
3. Upvote requests you want with a reply or reaction.

What belongs here vs. elsewhere

• Bug (something broken) → Operations & Troubleshooting, with wpfy debug output.
• How do I… → the relevant category (Site Management, Stack, etc.).
• I wish wpfy could… → here.

The maintainer triages requests against the roadmap and the decision log. Not every request becomes v1.

Frequently asked questions about Traefik, the shared edge proxy. See also Stack & Infrastructure and Architecture.

What is Traefik's role?

Traefik is the only shared component across sites. It sits at the edge as a reverse proxy, terminates SSL via Let's Encrypt, and routes traffic to each site's Nginx container. Every site attaches its own network to Traefik — Traefik never gets broad write access to site data.

Why one Traefik, not one per site?

A single shared Traefik lets all sites share automatic SSL, HTTP→HTTPS redirects, and a unified routing config without each site needing its own edge proxy. Site isolation is preserved because Traefik only proxies — it doesn't read or write site files or databases.

The Docker socket risk

Traefik reads the Docker socket to discover site containers dynamically. This is a known residual risk: a Traefik compromise could affect container discovery. Mitigations and the open question of socket-proxy adoption are tracked in the project's security docs. See Security.

How do I check Traefik is running?

wpfy stack status
wpfy debug

wpfy debug audits Traefik alongside Docker and every site.

Traefik won't start / 502 errors

1. wpfy debug — look for Traefik-specific checks.
2. Check the proxy Docker network exists: docker network ls | grep proxy.
3. Check Traefik logs: docker logs traefik --tail 50.
4. Confirm ports 80/443 are free on the host (no other web server bound).

Can I replace Traefik with Caddy/Nginx?

Not without an ADR. wpfy's architecture is Traefik-first. The edge proxy is part of the documented design; swapping it is an architecture change that requires updating docs/DECISION-LOG.md and the relevant ADR. See Architecture.

How to use wpfy debug and what to include when asking for help. See Operations.

What wpfy debug does

wpfy debug runs structured checks across:

• Docker Engine and Compose plugin
• The Traefik edge proxy
• Every managed site (runtime, scaffold, HTTP readiness)
• Certificate state where relevant

It returns structured facts — not raw command dumps — so the output is safe to share once secrets are redacted.

Run it

wpfy debug

For a specific site:

wpfy site status example.com
wpfy site info example.com

What to post when asking for help

1. The exact command you ran.
2. What you expected vs. what happened.
3. The wpfy debug output, redacted:

   $ wpfy debug
   [ paste here, replace any password/token/key with <redacted> ]
   

4. OS and Docker version:

   $ docker --version
   $ lsb_release -a
   

5. A redacted .env if the issue is site-specific.

See How to ask a good wpfy support question for the full template.

Other useful commands

• wpfy info — aggregate host + site operational facts
• wpfy log example.com — per-site log inspection
• wpfy secure — security audit baseline
• wpfy maintenance — maintenance mode controls

Common fixes

• Site not reachable: wpfy debug → check Traefik + site runtime checks → wpfy site status example.com.
• SSL failed: DNS/IP preflight — see the SSL FAQ.
• Restore failed: the archive must validate before the runtime stops. wpfy debug after a failed restore to confirm state.

Never paste

• Database passwords (MariaDB, Redis)
• API tokens
• Anything from .env (redact the whole file)
• SSH private keys
• ACME account keys

Frequently asked questions about SSL and the DNS/IP preflight. Post new questions in this category.

Why does wpfy site ssl fail with "DNS does not match public IP"?

wpfy refuses to request a Let's Encrypt certificate unless the domain's DNS A (and AAAA) records resolve to your server's public IP. This prevents failed ACME challenges and accidental certificate issuance for a domain you don't control.

Fix:

1. Check DNS: dig +short example.com
2. Check your public IP: curl -s ifconfig.me
3. They must match. Update DNS at your registrar and wait for propagation.

What does the preflight actually check?

preflight_ssl() compares the domain's resolved A/AAAA records against the server's detected public IPs. Only when they match does wpfy proceed to ACME issuance. See SSL Flow.

Can I test SSL without real DNS?

Yes, offline:

WPFY_TEST_DNS_IPS=1.2.3.4 WPFY_TEST_PUBLIC_IPS=1.2.3.4 wpfy site ssl example.com -le

This fakes a DNS/IP match so the preflight passes. Do not use this in production — it bypasses the safety check.

I enabled SSL. Now my site redirects oddly.

Enabling SSL updates WordPress home and siteurl to https://<domain> after the runtime restarts. If redirects fall back to HTTP, run wpfy site status example.com to confirm the runtime restarted, then clear WordPress/object cache. See Site SSL.

How do I force HTTPS?

Traefik handles the redirect once the SSL router is active. You don't need a separate plugin. If a site was created without -le, enable SSL:

wpfy site ssl example.com -le

Backups and restore

• wpfy site backup example.com — timestamped tarball to /var/lib/wpfy/backups/
• wpfy site restore example.com <backup>.tar.gz — restore files and database

Backups are never world-readable. Never restore one site's secrets into another. See Site Backup and Site Restore.

New to wpfy? Start here. This topic links the docs and walks through the fastest path from a fresh Ubuntu VPS to a running WordPress site.

1. Requirements

• Ubuntu 22.04 LTS or 24.04 LTS
• Docker Engine and Docker Compose plugin
• A domain name pointing to your server
• Ports 80 and 443 open

Full details: Requirements

2. Install wpfy

On a fresh Ubuntu VPS:

curl -fsSL https://raw.githubusercontent.com/wpfyorg/wpfy/main/install.sh | sudo bash

The installer sets up Docker, the wpfy CLI, and the shared runtime. Verify:

wpfy --help

Guide: Installation

3. Create your first WordPress site

wpfy site create example.com --wp

This provisions an isolated Docker Compose stack — Nginx, PHP-FPM, MariaDB, volumes, a private network — and installs WordPress. Add -le to issue a Let's Encrypt certificate after a DNS/IP preflight check:

wpfy site create example.com --wp -le

Guide: Quick Start

4. Check it's healthy

wpfy site status example.com

5. Next steps

• Site Commands — create, update, delete, backup, restore
• SSL — enable SSL on an existing site
• SFTP — per-site SFTP access
• Diagnostics — wpfy debug audits everything

Stuck?

1. Run wpfy debug and read the output.
2. Search this category — someone may have hit the same thing.
3. Post a new topic in Getting Started using the support question template.

Welcome to the wpfy community forum. This is the place to talk about Docker-first WordPress server management on Ubuntu VPS.

What wpfy is

wpfy is a CLI for installing and managing isolated WordPress stacks on Ubuntu servers. Instead of installing Nginx, PHP, MariaDB, and Redis directly on the host, every site runs in its own Docker Compose project — separate containers, volumes, and networks. Traefik sits at the edge as a reverse proxy with automatic Let's Encrypt SSL.

You manage everything through a single CLI: wpfy.

Where to start

• New to wpfy? Read Getting Started in the docs, then post in the Getting Started category if you get stuck.
• Running a site? The Site Management category covers create, update, SSL, backup, restore, SFTP, and wp-cli.
• Infrastructure questions? Stack & Infrastructure covers Traefik, Docker, and server layout.
• Something broken? Run wpfy debug and post the output (redacted) in Operations & Troubleshooting.
• Have an idea? Feature Requests & Roadmap is for community input on deferred features.

Before you post

1. Read the Community Rules & Code of Conduct.
2. Search first — your question may already be answered.
3. Never paste secrets — redact database passwords, API tokens, and anything from .env before posting. See the project's security policy.

Beta status

wpfy is beta software. Test on a fresh Ubuntu VPS before relying on it for production sites. Feedback from real deployments moves the beta forward — that's what this forum is for.

Welcome aboard.

A good support question gets answered faster. Use this template when asking for help in Operations & Troubleshooting or any other category.

Template

What I tried:

wpfy site create example.com --wp -le

What I expected:
A working WordPress site at https://example.com with SSL.

What happened instead:
SSL preflight failed with "DNS A record does not match public IP".

Environment:

• OS: Ubuntu 24.04 LTS
• Docker: 27.3.1 (run docker --version)
• wpfy: run wpfy --version
• Domain registrar and DNS provider (if relevant)

Debug output (redacted):

$ wpfy debug
[ paste output here, with secrets replaced by <redacted> ]

Redacted .env (if a specific site is involved):

DB_NAME=wordpress
DB_USER=wp
DB_PASSWORD=<redacted>
DB_ROOT_PASSWORD=<redacted>
...

What to redact

Before pasting anything, remove or replace:

• All passwords (database, Redis, SFTP, WordPress admin)
• All tokens and API keys
• Private SSH keys
• ACME account keys or certificate private keys
• Any line in .env that looks like *_PASSWORD=*, *_TOKEN=*, *_KEY=*

Keep hostnames, container names, image tags, and error messages — those are not secrets and they help us diagnose.

How to get wpfy debug output

$ wpfy debug

It audits Docker, Traefik, and every managed site. If the output is long, paste it in a code block (triple backticks). Redact first.

One problem per topic

If you have two unrelated problems, start two topics. It keeps threads searchable and makes it easier to mark the right answer.

These rules keep the wpfy forum useful, safe, and welcoming for everyone. By posting you agree to follow them.

1. Be respectful

Treat everyone with respect. No harassment, personal attacks, hate speech, or discrimination. Disagree about technology; don't attack people.

2. Stay on topic

Post in the right category. Keep threads focused. If a discussion drifts, start a new topic and link back.

3. No secrets, ever

Never paste secrets into a post. This includes:

• Database passwords (MariaDB, Redis)
• API tokens (NodeBB, Let's Encrypt, GitHub, Docker registry)
• Anything from a site's .env file
• SSH private keys or host credentials
• ACME account keys

If you need to share config for debugging, redact first. Replace secret values with <redacted>. The project's security policy applies here too.

4. Search before you post

Someone may have already asked. Use the search bar. If you find a related thread, reply there instead of starting a duplicate.

5. Give enough context to help

When asking for help, include:

• What you were trying to do (the exact wpfy command)
• What you expected
• What happened instead
• The output of wpfy debug (redacted)
• Your OS and Docker version (ubuntu 24.04, docker 27.x, etc.)
• A redacted .env if the issue involves a specific site

See How to ask a good wpfy support question for a template.

6. No spam or self-promotion

This is a community for wpfy users. Don't post ads, affiliate links, or unrelated promotions. Sharing a relevant tool or blog post in the context of a real question is fine.

7. Respect the license

wpfy is AGPL-3.0. If you share modified source, follow the license terms.

Enforcement

Moderators may edit, move, lock, or delete posts that break these rules. Repeated or severe violations lead to account suspension. Appeals go in Forum Rules & Meta.

Reporting

Use the flag button on a post to report rule violations. Don't reply to argue — flag and let moderators handle it.