Skip to main content

Allow External Access

Secure external access

Use an NGINX reverse proxy to publish approved NIM experiences without exposing NIM Studio or administrative APIs.

Apps such as onboarding, password reset, and SAML sign-in are often intended for users outside the internal network. Place NGINX on a separate Windows Server in your DMZ and use it as the only public entry point; keep the NIM Service on the internal network or VPN.

warning

Do not expose NIM Studio or the administrative API to the public internet. Work with your network and security teams to validate the DNS, network paths, certificates, and allowed application routes before publishing a service.

Internet
  │ HTTPS (443) and HTTP (80, certificate renewal only)
  ▼
NGINX reverse proxy in the DMZ
  │ Publishes approved apps, password reset, onboarding, and SAML sign-in
  │ Denies Studio, administrative APIs, and other internal-only endpoints
  ▼
NIM Service on the internal network

Administrators should connect to NIM Studio directly over the internal network or VPN, not through the NGINX server.

Prepare NGINX​

  1. Use a Windows Server in the DMZ that can receive public traffic on ports 80 and 443 and can reach the NIM Service on its configured HTTP or HTTPS port.
  2. Create a public DNS record for the external hostname, such as apps.example.com, that resolves to the NGINX server.
  3. Download and extract the Windows build of NGINX, for example to C:\nginx.
  4. Start NGINX with ./nginx.exe to verify it runs, then stop it with ./nginx.exe -s stop.
  5. Use NSSM to run NGINX as a Windows service. Set its startup directory to C:\nginx, configure the service to start automatically, and restart it after configuration changes.
Set the public host URLThe external hostname must match the External host URL in NIM Preferences. Public DNS resolves it to NGINX; internal DNS can resolve the same name directly to the NIM server when appropriate for your environment.

Generate the NGINX configuration in NIM Studio​

NIM Studio can generate a configuration that separates approved public routes from internal-only routes.

  1. Sign in to NIM Studio as an administrator and go to Settings › HTTP.
  2. Select Download nginx config.
  3. Enter the internal NIM address and port that the NGINX server can reach.
  4. Choose whether to allow all hosted apps, expose only selected apps, or deny selected apps.
  5. Save the downloaded file as C:\nginx\conf\nimsuite.conf and include it inside the http { } block in C:\nginx\conf\nginx.conf.
# Inside the existing http { } block
include nimsuite.conf;

Confirm that the generated upstream block uses the internal NIM address and port. Re-download the configuration after changing NIM’s listening settings or changing the list of public apps.

Keep administrative routes internal​

Use the Studio-generated configuration as the source of truth for route restrictions. It should deny NIM Studio, /api/cmd/admin, the internal system-integration API routes, and the MCP endpoint unless you have deliberately designed and reviewed an exception.

Only expose the hosted apps that external users need. The default app is normally kept public by the configuration generator; review the generated allow or deny selection before deploying it.

Use Let’s Encrypt with NGINX​

NGINX terminates the public HTTPS connection, so it needs its own certificate. On Windows, win-acme is a practical ACME client for obtaining and renewing a free Let’s Encrypt certificate.

  1. Download win-acme and extract it, for example to C:\win-acme.
  2. Create an ACME webroot at C:\win-acme\webroot and add the following location inside the port 80 server block in nimsuite.conf:
location /.well-known/acme-challenge/ {
    root C:/win-acme/webroot;
}
  1. Run nginx -t, then restart the NGINX service.
  2. Run wacs.exe, choose a new certificate with simple options, enter the public hostname, and use FileSystem validation with C:\win-acme\webroot.
  3. Add the generated certificate and key paths to the HTTPS server block:
ssl_certificate     C:/ProgramData/win-acme/.../apps.example.com-chain.pem;
ssl_certificate_key C:/ProgramData/win-acme/.../apps.example.com-key.pem;
  1. Run nginx -t and restart NGINX again.

Port 80 must remain publicly reachable for HTTP-01 validation and renewal. win-acme creates a scheduled renewal task; ensure NGINX reloads after a successful renewal so it serves the updated certificate.

Verify the deployment​

  • Confirm an approved app loads at https://apps.example.com/app/<app-name>.
  • Confirm Studio and /api/cmd/admin return 403 from the public hostname.
  • Confirm onboarding, password reset, and SAML sign-in work as expected.
  • Optionally run ./wacs.exe --renew --force, restart NGINX, and confirm the certificate has been updated.

Troubleshooting​

SymptomWhat to check
NGINX does not startRun nginx -t from C:\nginx; confirm the NSSM service startup directory is C:\nginx.
502 Bad GatewayVerify the generated upstream address and port, and confirm NGINX can reach the NIM Service.
A public app failsRe-download the Studio-generated configuration and review the app allow or deny selection.
Studio is reachable publiclyStop using the configuration, re-download it from Studio, and verify the restrictive routes are present.
ACME validation failsConfirm the public hostname resolves to NGINX, port 80 is reachable, and the ACME location has been loaded.
Certificate renewal failsCheck the win-acme renew (main) scheduled task and run ./wacs.exe --renew to view the error.