Blue Knight Panel · Hostless

A Node.js proxy panel adapted for Hostless, with VLESS, VMess, Trojan, subscriptions, engine recovery, and resource monitoring.

YouTube · @BlueKnight-Net · Telegram · @BlueKnight_Net

1. Sign in to Hostless and create an App connected to this GitHub repository.

2. Select the blue-knight-net branch.

3. Use these build and startup settings:

   Setting	Value
   Build system	Detect automatically
   Working directory	/
   Build command	Leave empty
   Start command	npm start
   Internal port	Use the PORT supplied by Hostless

4. Attach a persistent volume at /data to keep panel settings and downloaded engines across deployments. Choose its capacity in the hosting dashboard; storage may incur charges.

5. Keep the default TCP health check, or use an HTTP check on /knight/login.

6. Deploy. The first startup downloads sing-box and Xray-core from GitHub, so allow time for both engines to install and start.

7. Open https://YOUR-APP.hostless.app/knight, create your panel password, and open Subscriptions to import a link into your client.

The included hostless.yaml declares automatic builds and npm start. The app binds to 0.0.0.0 and reads Hostless's PORT; do not change the internal port to 443.

See the official Hostless Node.js deployment guide for platform setup.

For a generated *.hostless.app domain, the panel automatically generates HTTPS/TLS links on public port 443, without pinning its internal self-signed certificate. The internal container port can be different.

Open the panel once after deployment so it can learn and save the public domain. Refresh your client subscription after changing a domain, UUID, or deployment configuration.

Each deployment learns its own domain and saves it on its own data volume. The shared repository contains no personal deployment URL. Users can deploy this repository directly without a fork; give each app its own volume. If you previously set DOMAIN, FORCE_HOST, or PUBLIC_BASE_URL, update or remove stale values when changing the app's public address.

• VLESS, VMess, and Trojan over WebSocket: served by sing-box.
• HTTPUpgrade: served by sing-box; requires support from your client and the hosting proxy.
• VLESS-XHTTP: served by Xray-core; requires a client with XHTTP support.
• Shadowsocks over WebSocket: served by Xray-core where generated and supported by the client.

A working web panel does not by itself confirm that the proxy engines are running. Use a real connection or URL test in your client.

• Each engine has bounded crash-restart retries with backoff. The retry counter resets after a stable five-minute run.
• Engine watchdogs check local TCP listeners every minute and request a restart after three consecutive failed checks.
• A self-ping checks the panel every five minutes once its public domain is known, with a cache-busting request and visible [keepalive] success/failure logs.
• IPv4-only domain resolution is selected automatically when no public IPv6 interface is detected.
• Internal engine ports are assigned uniquely to avoid collisions between transports.

The self-ping cannot wake a suspended container or restart a stopped Node.js process. Availability still depends on the host's lifecycle and health checks.

If visiting the public panel brings a stopped app back, configure an external HTTP monitor to request https://YOUR-APP.hostless.app/knight/login every 5–10 minutes. That monitor must run outside this app so it can still send requests when the app is suspended. Use GET requests and expect HTTP 200. A successful page check confirms panel reachability, not an end-to-end proxy connection.

GitHub Actions can run a scheduled check from a separate repository, but schedules can be delayed and public-repository schedules are disabled after 60 days without repository activity. See GitHub's schedule documentation. A paused app that requires the Hostless Resume control cannot be restarted by an HTTP monitor.

This repository includes a reusable availability-check workflow. It has no hardcoded app domain and is skipped until a URL is configured.

1. Fork this repository, or copy that workflow into .github/workflows/ in a separate GitHub repository you own. Your Hostless app can continue deploying directly from this shared repository.
2. In your monitoring repository, open Settings → Secrets and variables → Actions → Variables. Add a repository variable named PANEL_URL containing your own public HTTPS URL, for example https://YOUR-APP.hostless.app. For a custom panel path, supply the complete login URL instead.
3. Ensure the workflow exists on that repository's default branch. In a fork, enable Actions if GitHub asks.
4. Open Actions → Hostless availability check → Run workflow to test it. After setup, it checks your URL every ten minutes.

The optional URL input on Run workflow is for that one run only; scheduled runs use the PANEL_URL repository variable. No panel password, subscription token, or Hostless API key is required. Each user configures their own monitoring repository; the shared upstream workflow cannot discover every user's independent Hostless deployment automatically.

The Usage tab includes per-protocol traffic counters and live CPU/RAM readings. When container metrics are available, they include the proxy engines; fallback readings are labelled as panel-process readings.

App data storage measures files in the data directory, refreshed every 30 seconds. It does not report shared host-disk usage or invent a storage quota. Check the hosting dashboard for your purchased capacity and available allowance.

Expiry and credit cards show previously saved values when present. They are not connected to Hostless billing; unknown values are shown as Not provided.

Keep the /data volume. It stores the panel login, UUID, subscription token, certificates, traffic counters, and engine files. Without persistent storage, redeployment may reset these values and require new client configs.

If you use another mount path, set BK_DATA_DIR to that path. Attaching an empty volume over an existing data directory hides its previous contents, so back up existing data before switching storage.

Normal deployment on a generated Hostless domain does not require these variables. Explicit values override automatic behavior.

Keep passwords and subscription tokens private. Configure secrets in your hosting dashboard rather than committing them to Git.

• Panel opens, configs fail: check runtime logs for successful sing-box and Xray startup. WebSocket configs need sing-box; XHTTP needs Xray.
• bad path errors: update your client subscription and use the matching transport. VMess WebSocket uses a path ending in vmess; VMess HTTPUpgrade uses vmess-hu.
• IPv6 network is unreachable: set BK_IPV4_ONLY=true if automatic interface detection does not match your host's routing. Clients sending literal IPv6 destinations still need to use IPv4 or domain destinations.
• Deployment is queued or fails Hostless-file validation: inspect the deployment configuration and platform error before changing proxy settings. Confirm the selected branch and the included hostless.yaml.
• Credentials or configs reset after redeployment: verify that the persistent volume is attached and the startup log points to its data directory.

• Watch tutorials on YouTube
• Follow updates on Telegram