Overview
When Let's Encrypt certificate failed, slow down and isolate the failure: build, runtime, networking, DNS, credentials, or resources. Better-PaaS gives you logs, deployment history, server tools, and configuration screens to work through the problem systematically.
Start here
First, verify DNS, ports, and domain routing before retrying. Then check the most recent deployment logs and confirm whether the app failed during build, startup, health check, or routing.
Step-by-step checks
Work from the app outward: source code, build output, runtime command, env vars, container health, router, DNS, then external services.
- Read the latest logs
- Confirm the app listens on the expected port
- Verify required environment variables
- Check database or service containers
- Retry after fixing one variable at a time
Prevent it next time
Keep build scripts explicit, document env vars, set backups for stateful apps, and verify a staging deployment before switching a production domain.
Let's Encrypt failure checklist
ACME failures are almost always DNS, firewall, or routing - not the app framework.
- dig +short yourdomain.com must return your VPS IP
- Ports 80 and 443 open in cloud firewall and ufw
- No other process bound to port 80 on the host
- Domain added in Better-PaaS only after DNS propagates
- Check Caddy logs on the server for specific ACME error text
FAQ
Can Better-PaaS show logs for Let's Encrypt certificate failed?
Yes. Better-PaaS streams container logs in the dashboard and stores logs on disk for troubleshooting.
Should I redeploy immediately?
Only after changing one likely cause. Repeated redeploys without reading logs usually hide the real issue.