Site Launch & Triage: bare VPS to HTTPS + layer diagnosis

    1

    Bare VPS to multi-site HTTPS, then four-layer triage for 502s, 404 storms, cert expiry, DNS and CDN origin exposure.

    $35

    Secure checkout via Stripe

    Money-back guarantee

    Converts to your local currency at checkout

    Security scanned

    Works with the AI Agents you already use

    Claude CodeClaude CodeCursorCursorCodex CLICodex CLIMuseMuseDotsDots+21 more

    Site Launch & Triage: bare VPS to HTTPS + layer diagnosis

    Example session with this skill installed

    The site worked at 09:00 and now every path returns 502. nginx is running, the certificate is valid. Tell me which layer broke and do not tell me to restart things at random.

    • Read your context and instructions
    • Compiled the site launch

    Verdict

    layer 4 (application). Layers 1-3 all return a verdict, so the walk stops here - nothing above this line is a candidate.

    LayerCheckResultVerdict
    1. DNSA record for shop.example.com203.0.113.42, TTL 300ok - resolves to the origin, not to a stale CDN edge
    2. ConnectivityTCP 443 to originopen, 12 msok
    3. TLSchain, expiry, SNIvalid, 47 days left, correct SANok
    4. Applicationupstream behind the vhost127.0.0.1:3000 refuses connectionFAIL - this is the layer

    What the 502 actually says

    connect() failed (111: Connection refused) while connecting to upstream - nginx answered, the process behind it did not. Two siblings of this failure look identical from a browser and are worth ruling out with the same evidence:

    • port already in use - the app started, lost the port to another process, and is alive but not listening on 3000;

    disk full - the app cannot write its log, dies at startup, and leaves nginx with a closed upstream. Check df -h before restarting anything: restarting into a full disk just repeats the crash every time the log rolls.

    Next steps, in this order

    1. ss -ltnp | grep 3000 - if nothing listens, the app is down; if something else holds the port, that is the whole incident.
    2. df -h on the partition holding the logs. Above 95%, clear space before restarting.
    3. Start the app, then re-run the same four layers to confirm the verdict moved - a 502 that disappears without a layer changing its answer is a symptom, not a fix.
    4. Once it is up, check the origin-exposure pattern: curl -I http://203.0.113.42 should not serve the site directly. If it does, the CDN is optional and so is the protection.

    The doctor is read-only: it does not log into the server, does not edit configs, does not restart services. It reports what each layer answered.

    Connects securely to your tools. The creator never sees your data.

    About this skill

    Two jobs, one skill: getting a bare VPS to multi-site HTTPS correctly the first time, and finding out which layer is actually broken when it goes down.

    The launch side is a five-stage pipeline (base hardening → reverse proxy → certificates → sites → verification) with the ordering constraints that matter: why the certificate must be issued after DNS resolves, why the default server block must exist before the first vhost, why the CDN must not be switched on before the origin is locked down.

    The triage side is four layers (DNS, connectivity, TLS, application) with a stopping rule: do not look at the next layer until the current one returns a verdict. It covers 502 / 504, 404 storms, certificate expiry, DNS not propagating, port already in use, disk full, and the CDN-origin-exposed pattern where the site works but anyone can hit the origin IP directly.

    Includes 12 triage trees, a launch playbook, an nginx multi-site template with inline explanations, and a read-only doctor that checks DNS, certificates, ports and disk.

    What it does not do: it will not log into your server or edit configs remotely, it offers no way around ICP filing or risk controls, and it promises no uptime SLA, only a triage path that is executable and falsifiable.

    Does not manage cloud console actions (security groups, snapshots). Requires existing SSH access. Audits configuration but does not auto-remediation live services.

    How to use

    1. 1

      Connect your agent to the Agensi MCP

      Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup

    2. 2

      Sign in to Agensi

      Your agent shows a sign-in link. Sign in and click Allow.

    3. 3

      Ask for what you need

      Your agent loads this skill and uses it on your task. It always asks before any payment.

    Reviews

    No reviews yet

    Be one of the first to try it. Every listed skill goes through the trust checks below.

    Security scanned

    Checked by our 8-point scan before listing

    Fresh listing

    Recently published to Agensi

    Money-back guarantee

    Doesn't do what its page promises? You get your money back.

    Trust & safety

    Security scan

    Security scan passed 7 days ago

    Requires

    A
    Python

    Permissions

    Terminal / Shell
    Network Access
    Read Files
    Write Files

    Allowed Hosts

    example.com
    a.com
    api.ipify.org;
    cdn.example.com
    www.example.com
    ip
    $host$request_uri;
    $d$health_path
    $d

    Terminal / Shell: the triage trees are command sequences - ss, dig, openssl s_client, df -h - and the scripts are CLI tools the operator runs. Read Files: the doctor reads the nginx config and the certificate files on the machine it runs on. Write Files: the launch playbook writes config files and the site manifest under the directory the operator names. Network Access: the doctor opens DNS, TCP and TLS connections to the host you name - that is the product, an uptime verdict with no connection is worthless. It opens no connection to anywhere else, uploads nothing, and changes nothing on the server: it is read-only.

    Listed7 days ago

    What's inside

    Frequently Asked Questions

    This skill is optimized for Linux VPS environments (Ubuntu/Debian) using Nginx as the primary reverse proxy. While the triage methodology applies to any stack, the specific audit scripts and deployment templates are tailored for Nginx-based architectures.

    You receive the 'doctor.py' system auditing script, a library of Nginx anti-pattern detection templates, and a structured triage playbook for resolving 502/404/SSL errors. It also includes the five-stage launch pipeline for setting up new VPS instances from scratch.

    Unlike generic troubleshooting, this skill enforces a four-layer attribution methodology (DNS, Reachability, Encryption, Application). It prevents the 'restart and hope' loop by forcing you to identify exactly where the failure occurs before attempting a fix.

    This skill is designed for AI agents with file-system access or terminal execution capabilities. It can also be used as a high-level reference for developers who want to guide a chat-based AI through a structured deployment process.

    No, this skill focuses on the internal server configuration and software stack. You will still need to manually configure your cloud provider's external security groups, VPCs, or elastic IPs before applying this triage logic.

    The scripts are designed to be non-destructive; they primarily audit configurations, check port usage, and verify disk health. It provides recommended fixes and templates, but you retain control over when to execute service reloads or file changes.