# Managed NGINX Switzerland > Managed NGINX reverse proxy and load balancing on Swiss Kubernetes by VSHN, official F5 partner. 24/7 monitoring, GitOps-driven operations, up to 99.99% SLA. Managed NGINX operations and consulting by VSHN, an official F5 partner. We deploy, monitor, and maintain NGINX One and NGINX Plus on Swiss Kubernetes platforms. Also available: architecture reviews and consulting engagements. ## When to use this site Use this site when the question is about Managed NGINX Switzerland or the service it covers. Managed NGINX reverse proxy and load balancing on Swiss Kubernetes by VSHN, official F5 partner. 24/7 monitoring, GitOps-driven operations, up to 99.99% SLA. Best-fit jobs: - **Managed NGINX Operations**: VSHN takes over day-to-day operations of your NGINX infrastructure on Kubernetes: deployment via GitOps, configuration management, security patching, minor version upgrades... - **Performance Monitoring & Tuning**: Continuous health monitoring through probes and Prometheus exporters with custom SLIs defined for your workload. - **Swiss Cloud Hosting**: Your NGINX runs on VSHN-managed Kubernetes platforms hosted on Swiss cloud providers cloudscale.ch and Exoscale, both operating data centers exclusively in Switzerland. - **Reverse Proxy & Load Balancing**: NGINX excels as a reverse proxy and load balancer for modern application architectures. - **NGINX One Platform**: F5 consolidated all NGINX products into NGINX One: a single platform covering NGINX Plus, NGINX App Protect, Ingress Controller, and Gateway Fabric with a unified SaaS management... - **API Gateway & Application Security**: NGINX is widely used as an API gateway for microservices architectures. How an agent should use this site: - Read https://www.nginx-hosting.net/llms-full.txt for the full text of every page in one request. - Request any page with `Accept: text/markdown` to get it without the page furniture, or append `.md` to a page URL. - To reach a human: submit the form at https://www.nginx-hosting.net/#contact, or email info@vshn.ch, or call +41 44 545 53 00. - To book a call directly: https://vshn.cal.vs.hn/nginx Do not use this site for product documentation, incident reports, or account support: these are public marketing pages with no login, no public API, and no customer data. ## Pages - [Homepage](https://www.nginx-hosting.net/): Managed NGINX – Swiss Hosted Reverse Proxy & Load Balancing - [Partner with VSHN on NGINX Operations | VSHN](https://www.nginx-hosting.net/partners.md) - [NGINX Sovereignty: Swiss Traffic Handling | VSHN](https://www.nginx-hosting.net/sovereignty.md) - [What is NGINX? Web Server, Proxy and Load Balancer](https://www.nginx-hosting.net/what-is-nginx.md) ## Features - **Managed NGINX Operations**: VSHN takes over day-to-day operations of your NGINX infrastructure on Kubernetes: deployment via GitOps, configuration management, security patching, minor version upgrades, certificate renewals, and incident response. Delivered as a managed service building block on APPUiO or Managed OpenShift. No dedicated ops hire needed. - **Performance Monitoring & Tuning**: Continuous health monitoring through probes and Prometheus exporters with custom SLIs defined for your workload. Our engineers tune worker processes, connection handling, caching strategies, and SSL/TLS configuration. Bottlenecks are identified proactively before they affect your users. - **Swiss Cloud Hosting**: Your NGINX runs on VSHN-managed Kubernetes platforms hosted on Swiss cloud providers cloudscale.ch and Exoscale, both operating data centers exclusively in Switzerland. VSHN is Swiss-owned with no foreign parent company. All contracts are governed by Swiss law with no exposure to the US CLOUD Act. Learn more in our [sovereignty assessment](/sovereignty/). - **Reverse Proxy & Load Balancing**: NGINX excels as a reverse proxy and load balancer for modern application architectures. Our engineers configure traffic distribution, SSL/TLS termination, HTTP/2 and gRPC proxying, WebSocket support, and health check strategies tailored to your microservices or containerised application backends. - **NGINX One Platform**: F5 consolidated all NGINX products into NGINX One: a single platform covering NGINX Plus, NGINX App Protect, Ingress Controller, and Gateway Fabric with a unified SaaS management console. VSHN provides consulting for NGINX One deployments: fleet-wide instance discovery, CVE tracking, configuration management, and policy enforcement across on-premises, cloud, and Kubernetes environments. - **API Gateway & Application Security**: NGINX is widely used as an API gateway for microservices architectures. Our engineers configure rate limiting, JWT validation, mTLS between services, and request routing. For application-layer protection, NGINX App Protect WAF defends against OWASP Top 10 threats and automated Layer 7 attacks without degrading performance. - **24/7 Support & Incident Response**: Our engineering team monitors your NGINX instances around the clock. Critical issues are responded to within one hour under the Guaranteed Availability tier. All incidents are handled by a dedicated incident commander to ensure rapid resolution and root-cause analysis. ## Included in Managed NGINX - NGINX deployment and lifecycle management via GitOps - 24/7 health monitoring with Prometheus and Grafana - Security patch monitoring and minor version upgrades - Configuration management via GitOps automation - SSL/TLS certificate management and automated renewal - Logical backups with documented restore procedures - Migration assistance from other web server or proxy solutions - Architecture consulting and design review ## Managed NGINX FAQ ### What is NGINX and how does it work? [NGINX](/what-is-nginx/) is one of the most widely used open-source web servers in the world. Originally created by Igor Sysoev and now maintained by F5, NGINX serves as a high-performance web server, reverse proxy, load balancer, and HTTP cache. It is known for its event-driven architecture that handles thousands of concurrent connections with minimal memory usage. NGINX powers a third of the world's websites and is a critical component of modern application delivery infrastructure. ### What does VSHN's Managed NGINX service include? VSHN deploys, monitors, and maintains your NGINX instances on VSHN-managed Kubernetes platforms (APPUiO or Managed OpenShift). The service includes GitOps-driven deployment and configuration management, 24/7 health monitoring, security patching, minor version upgrades, TLS certificate management, logical backups with documented restore procedures, and incident response. Major version upgrades are handled as planned changes. VSHN manages the infrastructure layer. Application-level concerns such as query optimization or business logic remain the customer's responsibility. For teams that operate their own NGINX, we also offer consulting-only engagements covering architecture reviews, performance audits, and NGINX One fleet management. ### What SLA is available for Managed NGINX? VSHN offers tiered service levels. A best-effort tier provides monitoring and operational management suitable for development and staging environments. A guaranteed availability tier adds up to 99.99% SLA with 24/7 incident response and one-hour response time for critical issues. Pricing depends on the number of instances, the required SLA tier, and the underlying Kubernetes platform. Contact us for a scoped estimate. ### How does VSHN handle backups and disaster recovery for NGINX? VSHN maintains logical backups of all NGINX configurations, virtual host files, and deployment manifests using k8up on Kubernetes. Restore procedures are documented and tested. Disaster recovery is built into the GitOps deployment model. A full NGINX environment can be rebuilt from version-controlled configuration within defined recovery time objectives. ### Can NGINX be deployed on Swiss cloud infrastructure? Yes. VSHN's managed Kubernetes platforms run on Swiss cloud providers cloudscale.ch and Exoscale, both operating data centers exclusively in Switzerland. If data residency is a compliance requirement, these providers are the default choice. We also support platforms on AWS (Zurich region), Google Cloud, and Microsoft Azure where Swiss regions are available. See our [sovereignty assessment](/sovereignty/) for details on how VSHN scores against the EU Cloud Sovereignty Framework. ### What is VSHN's relationship with F5 and NGINX? VSHN is an official F5 partner with certified expertise in NGINX deployment and operations. This partnership includes direct access to F5 engineering support, early security advisories, and validated deployment patterns for the full NGINX product family including NGINX One. Our engineers follow official best practices for NGINX configuration, performance tuning, and security hardening. ### Can NGINX run on Kubernetes? Yes. VSHN's Managed NGINX service runs natively on Kubernetes, deployed via GitOps on APPUiO or Managed OpenShift. We configure NGINX as Kubernetes-native workloads with proper health checks, horizontal pod autoscaling, and graceful shutdown handling. For Kubernetes ingress, note that the community Ingress-NGINX controller is retiring: best-effort maintenance ran until March 2026, with no further releases, bugfixes or security updates after that. VSHN advises on migrating off it, on the F5 NGINX Ingress Controller, and on the Gateway API implementations the project points to. ### What is NGINX One and how does it differ from NGINX Plus? [NGINX One](/what-is-nginx/) is F5's unified platform (launched 2024) that consolidates all NGINX products (NGINX Plus, the WAF now called F5 WAF for NGINX and previously NGINX App Protect, NGINX Ingress Controller, NGINX Gateway Fabric, and NGINX Instance Manager) into a single offering with one subscription. It adds a SaaS-based management console for fleet-wide visibility: instance discovery, CVE tracking by severity, certificate status, configuration recommendations, and performance metrics across all environments. NGINX Plus remains the core data plane for load balancing, API gateway, and reverse proxy workloads. As an F5 partner, VSHN provides consulting for both NGINX One and standalone NGINX Plus deployments. ### How do I get started with Managed NGINX from VSHN? To get started with VSHN Managed NGINX, contact us using the form below. Tell us about your current web server architecture, traffic volume, the challenges you are facing (for example high latency, complex proxy configurations, or scaling concerns) and your preferred cloud provider such as Cloudscale, Exoscale, AWS, or Google Cloud. We provide a written requirements analysis and cost estimate within one business day. There is no commitment at the scoping stage. ### Can agencies use managed NGINX for client web applications? Yes. [Web agencies and development firms](/partners/) use VSHN-managed NGINX to host client web applications on dedicated Swiss infrastructure. Each client gets an isolated NGINX setup with SSL, load balancing, and 24/7 monitoring. VSHN handles server operations, security patches, and performance tuning so your team focuses on building the application. Invoice billing and written service agreements make cost allocation to client projects straightforward. ## Contact us Ready to hand off your NGINX operations to a dedicated team? Contact us for a free requirements analysis and cost estimate. NGINX operations are scoped per engagement. We provide a written estimate within one business day. Booking: #contact --- ## Partner with VSHN on NGINX Operations | VSHN URL: https://www.nginx-hosting.net/partners/ # Partner with VSHN on NGINX Operations You bring the customer relationship and application expertise: application architecture, load balancing design, WAF/security configuration, performance optimization. VSHN brings 24/7 NGINX operations, Swiss data residency, F5/NGINX Plus licensing, and a 99.99% SLA as F5 Swiss Select Partner. Together you deliver a complete NGINX operations solution without either side building capabilities you don't have. ## How we collaborate **Lead Partner model.** For each project, one of us is the customer's single point of contact. Who leads depends on the project, agreed per engagement. The Lead Partner drives the project, handles invoicing, and owns first-level support. **Joint delivery.** You handle consulting, integration, and project management. VSHN handles infrastructure operations, monitoring, backups, and SLA. Or the other way around, depending on the project. Roles are agreed per engagement, not locked into a rigid structure. **Flexible billing.** Invoice the customer together or separately, agreed per project. Both models are supported: each party invoices their share directly, or one party invoices the full amount and redistributes. **Protected relationships.** No undercutting. Your customer stays your customer. Existing relationships are respected on both sides, with contractual protections for both parties. ## Division of labor for NGINX Operations | Your role | VSHN's role | |-----------|-------------| | Application architecture | NGINX operations and GitOps configuration | | Load balancing design | TLS management and certificate renewal | | WAF/security configuration | Monitoring and alerting | | Performance optimization | F5/NGINX Plus licensing | | Project management | 24/7 support and incident response | ## Partners delivering NGINX Operations Our partner network is growing. If you build or architect applications that need managed NGINX reverse proxy or load balancing operations, let's talk. See all VSHN partners at [servala.com/partners](https://servala.com/partners/). ## Become a partner Interested in delivering NGINX operations together? Let's explore how we complement each other. [Book a partnership discovery call](https://vshn.cal.vs.hn/nginx) or [start a partnership conversation](#contact). --- ## NGINX Sovereignty: Swiss Traffic Handling | VSHN URL: https://www.nginx-hosting.net/sovereignty/ # NGINX Sovereignty: Your Reverse Proxy Sees Everything Your reverse proxy is the front door to every application. It terminates TLS, inspects headers, routes requests, and handles authentication tokens. Every HTTP request body, every cookie, every API key passes through it in plaintext after TLS termination. Sovereign traffic handling is not optional. It is the foundation of application-layer sovereignty. Cloudflare (US), AWS CloudFront + ALB (Amazon, US), Azure Front Door (Microsoft, US), and Akamai (US) all process your traffic on US-owned infrastructure under US law. Even with European points of presence, the operating company is subject to the [CLOUD Act](https://en.wikipedia.org/wiki/CLOUD_Act). A US court order can compel access to traffic data, including decrypted request bodies, without Swiss judicial process. NGINX is **open source** (BSD-2-Clause license). VSHN operates NGINX on Swiss infrastructure, keeping your traffic handling sovereign from edge to origin. ## Why NGINX is a strong choice for sovereignty NGINX powers over 30% of the world's web servers. Its open-source foundation provides: - **Full configuration transparency**: every routing rule, header manipulation, and rate limit is defined in config files you own - **No traffic exfiltration**: unlike CDN providers, NGINX does not route traffic through a vendor-owned global network - **BSD-2-Clause license**: one of the most permissive open-source licenses, with no usage restrictions - **No vendor telemetry**: NGINX does not phone home or share traffic metadata with third parties - **Portable configuration**: move between any infrastructure provider without reconfiguration F5 acquired NGINX Inc. in 2019, but the open-source NGINX project remains BSD-licensed and community-maintained. VSHN operates the open-source version, not F5's proprietary NGINX Plus. ## NGINX sovereignty compared | Dimension | Cloudflare (USA) | AWS CloudFront + ALB | Azure Front Door | Akamai (USA) | VSHN Managed NGINX | |-----------|-----------------|---------------------|-----------------|-------------|-------------------| | **Ownership** | Cloudflare (USA) | Amazon (USA) | Microsoft (USA) | Akamai (USA) | VSHN AG (Switzerland) | | **Governing law** | US law | US law | US law | US law | Swiss law | | **CLOUD Act** | Exposed | Exposed | Exposed | Exposed | Not exposed | | **Traffic inspection** | Cloudflare terminates TLS globally | AWS terminates TLS | Microsoft terminates TLS | Akamai terminates TLS | TLS terminated on Swiss infrastructure only | | **Data path** | Routes through US network backbone | AWS global edge | Microsoft global edge | Akamai global edge | Direct, Switzerland-only | | **Source code** | Proprietary | Proprietary | Proprietary | Proprietary | Open source (BSD-2-Clause) | | **TLS termination** | Cloudflare-controlled | AWS-controlled | Microsoft-controlled | Akamai-controlled | Customer-controlled | | **Operations team** | USA | USA | USA | USA | Switzerland ([Swiss-only option](https://products.vshn.ch/support_plans.html#_option_switzerland_only_support)) | ## The traffic visibility argument When you use a US-operated CDN or load balancer, the operating entity can see: - **Every request and response**: headers, cookies, POST bodies, API payloads in cleartext after TLS termination - **Authentication tokens**: session cookies, JWTs, OAuth tokens flowing through the proxy - **Internal routing patterns**: which backends exist, how traffic is distributed, what paths are active - **Client metadata**: IP addresses, geolocation, device fingerprints, request frequency This is not about data-at-rest in a database. This is live traffic. The real-time activity stream of every user interacting with your applications stays under Swiss jurisdiction. Swiss law ensures this data stream stays under Swiss jurisdiction. ## VSHN sovereignty self-assessment We applied the EU's [Cloud Sovereignty Framework](https://commission.europa.eu/document/09579818-64a6-4dd5-9577-446ab6219113_en) (v1.2.1, October 2025) to our own services. This framework was used to score providers in the EU's [EUR 180M sovereign cloud tender](https://ec.europa.eu/commission/presscorner/detail/en/ip_26_833) in April 2026. Three pure-European providers achieved SEAL-3, while a consortium involving Google Cloud scored only SEAL-2. *This is a self-assessment, not a formal SEAL certification. We publish it for transparency so customers can evaluate our sovereignty profile using the same structured criteria the EU uses.* | # | Dimension | Weight | Assessment | Evidence | |---|-----------|--------|-----------|----------| | SOV-1 | Strategic | 15% | **Strong** | Swiss AG, no foreign parent, all shareholders Swiss citizens ([Commercial Register](https://zh.chregister.ch/cr-portal/auszug/auszug.xhtml?uid=CHE-275.566.226)) | | SOV-2 | Legal | 10% | **Strong** | Swiss law ([GTC](https://products.vshn.ch/legal/gtc_en.html)), no CLOUD Act, [EU adequacy decision](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en) | | SOV-3 | Data & AI | 10% | **Strong** | Swiss DCs by default. Sovereign key management via [Managed OpenBao](https://www.openbao.ch) + [Swiss HSM](https://cloud.securosys.com/cloudhsm) | | SOV-4 | Operational | 15% | **Strong** | Swiss 24/7 ops, [Swiss-only support option](https://products.vshn.ch/support_plans.html#_option_switzerland_only_support). All services on vanilla Kubernetes | | SOV-5 | Supply Chain | 20% | **Strong** | Infrastructure-agnostic, [customer chooses provider](https://servala.com/providers/). Open-source software | | SOV-6 | Technology | 15% | **Strong** | 100% open source. VSHN contributes to [K8up](https://github.com/k8up-io) (CNCF), [Crossplane providers](https://github.com/vshn), [Project Syn](https://github.com/projectsyn) | | SOV-7 | Security | 10% | **Strong** | [ISO 27001](https://www.vshn.ch/wp-content/uploads/2026/08/ISO-27001-certificate-VSHN-2026.pdf), ISAE 3402 Type II, Swiss SOC. [FINMA-regulated customers](https://www.vshn.ch/en/solutions/solutions-for-banks-and-financial-service-providers/) | | SOV-8 | Environmental | 5% | **Moderate** | DC operators: Green Datacenter AG (ISO 22301/27001/27701), [Exoscale sustainability](https://www.exoscale.com/sustainability/). [VSHN CSR policy](https://handbook.vshn.ch/corporate_social_responsibility_policy.html) | **Overall: SEAL-3 equivalent**, the same level achieved by the winners of the EU's own sovereignty tender. No provider worldwide achieved SEAL-4: it requires fully EU/EEA-sourced hardware supply chains and open-source foundations, structural gaps shared by every cloud provider. Try Swiss infrastructure: [Exoscale]({{partner:exoscale.signup_url}}) (Swiss IaaS). Want help choosing? [Contact us](#contact). ## Get a sovereignty assessment for your traffic infrastructure Routing traffic through Cloudflare or AWS CloudFront? We assess your sovereignty profile against the EU framework and plan a migration to NGINX on Swiss infrastructure where TLS termination stays under Swiss law. --- ## What is NGINX? Web Server, Proxy and Load Balancer URL: https://www.nginx-hosting.net/what-is-nginx/ # What is NGINX? NGINX is an open-source web server, created by Igor Sysoev and now maintained by F5. Calling it a web server undersells it: in most deployments it is doing three or four different jobs at once, and knowing which one you need is the whole of the decision. ## The four jobs **Serving static files.** HTML, images, stylesheets, JavaScript, straight from disk. It is very good at this and uses very little memory doing it. **Reverse proxy.** Requests arrive at NGINX and it passes them to an application behind it. The application is not exposed to the internet, does not have to handle TLS, and can be restarted without dropping connections at the edge. **Load balancer.** The same, spread over several instances, with health checks so a failed one stops receiving traffic. **HTTP cache.** Keeping responses so the application does not regenerate them. Less configurable than a dedicated cache, and often enough. Most real deployments use it as all four, which is why "what is NGINX" gets confusing answers. It is one process doing whichever of these you configured. ## Why it displaced what came before The architectural difference is worth one paragraph because it explains the reputation. Older servers handled each connection with a process or thread, so a thousand simultaneous connections meant a thousand of those, most of them idle and all of them consuming memory. NGINX is event-driven: a small number of worker processes handle many connections each, doing work only when a connection actually has something to say. Idle connections cost almost nothing. That is why it holds large numbers of concurrent connections in modest memory, and why it became the default in front of applications that could not. ## Open source, NGINX Plus, and NGINX One This is where most confusion sits, and it is a purchasing question rather than a technical one. **NGINX open source** is the software described above. It is free, it is what almost everyone runs, and it is entirely sufficient for the large majority of deployments. **NGINX Plus** is F5's commercial version, adding capabilities such as advanced load balancing behavior, session persistence, richer monitoring and an API for reconfiguration without a reload, plus vendor support. **NGINX One** is F5's newer packaging around the commercial offering. What Plus adds, in the terms F5 uses for it, is advanced traffic control, security and observability on top of open source NGINX. Two capabilities account for most of the reasons organizations actually buy it. **Authentication at the edge, via JWT validation.** NGINX Plus can validate a JSON Web Token before the request reaches your application: it checks the signature, the expiry and whatever claims you require, and rejects or redirects anything that fails. Signed, encrypted and nested tokens are all supported. The practical shape is the one people want: a request arriving without a valid token, or with an expired one, is sent to the login page by the proxy rather than by every application behind it. That moves session checking out of each application and into one place, which is the same argument an identity provider makes one layer up, and it is why this comes up so often with teams who have several applications and one login. **A web application firewall, as a separate add-on.** F5 WAF for NGINX, previously called NGINX App Protect, is a distinct product rather than part of the Plus subscription. It filters malicious traffic before it reaches the application, and the part that usually motivates the purchase is bot defense: comprehensive protection against automated attacks and bots, which is most of what an internet-facing application receives. Worth being clear that this is a second line item. "We need the WAF" and "we need Plus" are two purchases, and quotes that assume otherwise are a common surprise. The rest of the Plus feature set is real and rarely the reason anyone buys: - **Active health checks.** Open source NGINX notices a backend is dead when a request fails on it. Plus probes backends independently and takes them out before a user finds them. - **Configuration changes without a reload.** An API-driven configuration that applies traffic changes with no reload, which matters when the upstream list changes constantly, as it does anywhere with autoscaling. - **Session persistence** beyond what hashing gives you, for applications that hold state per user. - **State synchronization and failover** across instances, so a pair or cluster behaves as one. - **Real-time observability**, meaning per-upstream metrics rather than inference from access logs. **NGINX One** is F5's packaging of the whole line, launched in 2024: NGINX Plus, App Protect WAF, the Ingress Controller, Gateway Fabric and Instance Manager under one subscription, with a SaaS console for fleet-wide visibility including instance discovery, CVE tracking by severity and certificate status. The case for it is fleet management rather than any single capability, so it lands when you have many instances and cannot answer "which of them is unpatched". The honest guidance: start with open source. Adopt the commercial version when you can name which of the capabilities above you need, not because a product page implies the free one is a trial. In practice the question that decides it is usually whether you want authentication or bot filtering handled at the edge; if neither, open source covers most single-application deployments indefinitely. ## The Kubernetes ingress confusion, and a deadline If you arrived here from Kubernetes, the thing you have been reading about is probably not plain NGINX. An ingress controller watches Kubernetes for routing rules and generates configuration for a proxy. Several use NGINX as that proxy, and they are separate projects with different maintainers, different feature sets and annotations that are not interchangeable. So "we use NGINX" inside a Kubernetes conversation and outside it can mean quite different things. **One of them is now retiring, and this is the most important thing on this page if you run Kubernetes.** The community controller, Ingress-NGINX, is being retired: best-effort maintenance continued until March 2026, and the project states there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. Its own guidance is that anyone not already using it should not deploy it. That is not a deprecation notice to file for later. An internet-facing component that will not receive security fixes is a dated liability, and Ingress-NGINX is one of the most widely deployed pieces of software in the Kubernetes ecosystem, which means a great many clusters are affected and many of their operators have not noticed. If you run it, there are two questions worth answering this quarter: what you are moving to, with the Gateway API implementations being where the project points, and how long that migration takes given every routing rule and annotation in your cluster is expressed in the controller you are leaving. ## When you need it - **An application server that should not face the internet directly.** Most application runtimes are not built to be edge-facing, and this is the standard answer. - **TLS termination in one place**, so certificates are managed once rather than in every application. - **More than one instance of anything**, at which point something has to distribute traffic. - **Static content next to a dynamic application**, served without waking the application at all. ## When you do not **A managed platform that already fronts your application** has this layer, and adding your own duplicates it. **A CDN alone**, for a purely static site with no dynamic origin, is less to run. **When what you actually want is caching**, look at a cache built for it. NGINX caches; [Varnish](https://www.varnish.ch) is designed around it, with a configuration language for rules NGINX cannot express. ## What running it involves - **TLS and certificate renewal.** Automated issuance is standard now, and the automation is a thing that can break quietly until a certificate expires. - **Configuration is easy to get subtly wrong.** Location matching, header forwarding and proxy buffering have behaviors that are correct and surprising. A reload with a bad config is worse than a syntax error, because a syntax error at least stops. - **Timeouts and buffer sizes.** Defaults are conservative and cause mysterious failures on large uploads and slow backends. - **Security patching.** It is the process facing the internet. - **Logs are the useful signal.** Access and error logs are where a wrong route or a failing backend actually shows up. ## Where VSHN fits VSHN deploys, monitors and maintains NGINX on Swiss infrastructure, including the TLS, configuration and patching work above, as part of an application delivery stack rather than as a component in isolation. If you are still deciding what to run at the edge, the useful first question is which of the four jobs is the one you actually have. It changes the answer more than the choice of software does. [Get a cost estimate](#contact)