DevOps i chmura · Integracja z narzędziem
render-web-services
/render-web-services
Konfiguruje usługi webowe Render: wiązanie portów, TLS, health checki, domeny, auto-deploy i dyski trwałe.
Dla kogo
- Autor
- kael-odin ↗
- Repozytorium
- codex-plugins-zh ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 25.10.2026
Ocena i bezpieczeństwo
100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
- Pliki w paczce
- 5
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Przestarzałość
Brak sygnałów. Repozytorium zmienione 25.10.2026, bez odwołań do wycofanych modeli i API.
Licencja
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Konfiguruje usługi webowe Render: wiązanie portów, TLS, health checki, domeny, auto-deploy i dyski trwałe.
Oryginalny opis (EN)
配置 Render web service——端口绑定、TLS、健康检查、自定义域名、自动部署、PR 预览、持久化磁盘及部署生命周期。当用户需要搭建 web service、修复健康检查失败、添加自定义域名、配置零停机部署,或排查端口绑定问题时使用。
Jak działa
- When to Use
- Port Binding
- TLS and HTTPS
- Health Checks
- Custom Domains
- Auto-Deploy and PR Previews
- Persistent Disks
- Deploy Lifecycle
- Free Tier Notes
- References
Sekcje z nagłówków SKILL.md, w oryginale · 101 linii, 856 słów
Podgląd SKILL.md
--- name: render-web-services description: "配置 Render web service——端口绑定、TLS、健康检查、自定义域名、自动部署、PR 预览、持久化磁盘及部署生命周期。当用户需要搭建 web service、修复健康检查失败、添加自定义域名、配置零停机部署,或排查端口绑定问题时使用。" license: MIT compatibility: Render web services (native runtimes or Docker) metadata: author: Render version: "1.0.0" category: compute --- # Render Web Services This skill covers **Web Service** behavior on Render: how traffic reaches your process, how deploys go live, and how optional features (domains, disks, auto-deploy) interact. Use it alongside Blueprint and networking skills when wiring `render.yaml` or Dashboard settings. ## When to Use - Configuring or debugging **port binding**, **PORT**, or **multi-port** web services - **TLS/HTTPS** expectations at the edge vs inside the container - **Health checks** blocking or rolling back deploys - **Custom domains**, DNS, and certificate provisioning - **Auto-deploy**, **CI-gated deploys**, and **PR preview** generation - **Persistent disks** and their impact on scaling and zero-downtime - **Deploy lifecycle**: build, pre-deploy, swap, drain, **rollback**, shutdown delay Deeper patterns live under `references/` (health checks, domains, deploy phases). ## Port Binding - Listen on **`0.0.0.0`** (all interfaces). Binding only to **`localhost`** or **`127.0.0.1`** prevents Render’s proxy from reaching your app. - Use the **`PORT`** environment variable for the HTTP listen port. Render sets it for you; the **default is often `10000`** and you can change the configured value in the service **Settings** in the Dashboard. - **Reserved ports** (do **not** bind your application to these for normal traffic): **`18012`**, **`18013`**, **`19099`**. ### Multi-port Web Services - Only **one** port receives **public** HTTP traffic: the port aligned with **`PORT`**. - **Additional** open ports are reachable on Render’s **private network** only (not from the public internet through the same public URL pattern). ## TLS and HTTPS - **TLS terminates at Render’s edge.** The edge speaks HTTPS to clients; your process typically receives **plain HTTP** on `PORT`. - **HTTPS redirect** for clients is handled by the platform; users hitting HTTP are redirected appropriately at the edge. - **Do not terminate TLS inside the app** for the primary public listener unless you have a rare, explicit need—standard Web Services assume HTTP behind the proxy. ## Health Checks - Configure a path via **`healthCheckPath`** in a Blueprint or the **Health Check Path** field in the Dashboard. - Render issues **HTTP GET** requests to that path. Responses must be **`2xx` or `3xx`** for success. - **Failed health checks** prevent a new deploy from **going live** (the deploy does not succeed in taking production traffic as expected). - Render probes on a **repeat interval** with a per-request **timeout**; both are **configurable** in service settings (see Dashboard). Failed checks during rollout prevent the new revision from receiving traffic. - Check frequency, timeouts, and tuning guidance in `references/health-check-patterns.md`. ## Custom Domains - Point DNS with a **CNAME** to **`[service-name].onrender.com`** (use your service’s hostname from the Dashboard). - Render **automatically provisions and renews** TLS certificates for verified domains. - **Apex** (root) domains need provider-specific **CNAME-like** or flattened records where plain CNAME at `@` is unsupported. - **Wildcard** domains (e.g. `*.example.com`) are supported when configured and verified. - Multiple custom domains per service are supported; Blueprints can list them under the **`domains`** field. See `references/custom-domains.md` for Dashboard steps, verification, and troubleshooting. ## Auto-Deploy and PR Previews - **`autoDeployTrigger`** (Blueprint) / auto-deploy settings control when production deploys run: - **`commit`** — deploy on every push to the tracked branch - **`checksPass`** — deploy only when required **Git checks** pass - **`off`** — **manual** deploys only (Dashboard, CLI, hooks) - **PR previews** are configured under Blueprint **`previews.generation`** (and related preview settings); generation behavior depends on repo integration and plan. ## Persistent Disks - Attach disks via the **`disk`** field in a Blueprint (or equivalent Dashboard storage settings). - A service with an attached persistent disk is **single-instance** only: **horizontal scaling** is not available in that configuration. - **Zero-downtime deploys are disabled** when a persistent disk is attached—deploys follow a different rollout pattern. - **Disk size increases** are allowed; **decreases** are not. - The disk is **not mounted during the build phase**—only at **runtime** in the running service. ## Deploy Lifecycle Typical flow: 1. **Build** — clone repo, run **`buildCommand`**, produce the runnable artifact/image. 2. **Pre-deploy command** (optional) — runs in the **new** image **before** traffic switches; use for **migrations**. If it **fails**, the deploy is **canceled**. 3. **Deploy** — new instances start; health checks must pass before traffic moves. 4. **Zero-downtime swap** (when applicable) — traffic shifts to new instances; **old instances drain** in-flight work. - **`maxShutdownDelaySeconds`** (range **1–300**, **default 30**) bounds how long old instances may continue handling requests during drain before shutdown. - **Rollbacks** — revert to a **previous successful deploy** from the Dashboard. Full sequence, hooks, filters, and CLI notes: `references/deploy-lifecycle.md`. ## Free Tier Notes Free Web Services have **separate limits**: e.g. **no custom domains** on the free instance type, and services **spin down after inactivity** (cold starts on next request). Treat free-tier behavior as distinct from paid Web Service defaults when advising on domains, uptime, and scaling. ## References | Topic | File | |--------|------| | Health check design, timeouts, pitfalls | `references/health-check-patterns.md` | | Domains, DNS, TLS verification | `references/custom-domains.md` | | Build, pre-deploy, drain, rollbacks, triggers | `references/deploy-lifecycle.md` | ## Related Skills - **render-deploy** — Blueprints, first-time deploy, `render.yaml` structure - **render-docker** — Docker-based Web Services and image/runtime details - **render-networking** — Private network, internal URLs, multi-port private listeners - **render-scaling** — Instance counts, plans, and scaling constraints (including disk interactions)
Pliki w paczce (5)
- SKILL.md 7 KB
- agents/openai.yaml 1 KB
- references/custom-domains.md 3 KB
- references/deploy-lifecycle.md 4 KB
- references/health-check-patterns.md 3 KB
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · kael-odin/codex-plugins-zh | 100 | MIT |
| render-oss/skills | 100 | MIT |
Migawka bazy z 28.10.2026 · wersja paczki 4ad6fa1e3fea (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 86devops/deploy-render
Wdraża aplikacje full-stack na Render według pliku render.yaml, w tym usługi webowe, workery, strony i bazy. - 100render
Wdraża aplikacje webowe, API, strony statyczne, workery, zadania cron i Postgres na Render przez Blueprint render.yaml, w tym zmienne środowiskowe, auto-deploy z Gita, autoskalowanie i domeny. - 100render-private-services
Konfiguruje prywatne usługi Render dostępne tylko w sieci wewnętrznej, np. dla API, mikrousług i gRPC. - 100render
Wspiera pracę z platformą chmurową Render: blueprinty render.yaml, Web Services, Background Workers, Cron Jobs i zarządzany PostgreSQL przy wdrażaniu aplikacji webowych i API. - 100render-domains
Konfiguruje własne domeny i certyfikaty TLS na Render: ustawienia DNS, rekordy CNAME, domeny apex i wildcard oraz diagnostykę wystawiania certyfikatów. - 100render-private-services
Ustawia prywatne usługi Render, które przyjmują ruch wyłącznie z innych usług Render przez sieć prywatną.