Response speed depends on the network, API, PostgreSQL, and data size. Caching helps repeated reads of the same public content; it does not replace slow-query optimization or speed up writes.
Enable caching where delay is acceptable
In Generator UI, open Content → the desired persistent or virtual entity settings → Access → External READ access. Allow anonymous List or Get, enable Cache public responses, set TTL, and save. Caching is disabled by default; initial TTL is 30 seconds, with 1–3600 allowed. Generate and a new release then apply settings to backend and Nginx.
For a site with virtual pages, enable caching on projections the site actually requests. For documentation, consider the catalog and open article route separately. Source entity settings are not automatically inherited by projections. Leave caching disabled when visitors must see changes immediately.
Caching works in production/prod-local through generated Nginx for anonymous external List/Get and successful 200 responses. Requests with Cookie or Authorization bypass it. Admin operations, writes, and errors are not cached. Direct Go backend requests do not use this Nginx cache. Query parameters are part of the key, keeping different filters and pages separate.
Writes do not clear the cache automatically. With TTL 30, for example, a visitor may see the previous article text for up to 30 seconds after an edit. This also applies to related data changes inside virtual entities. Access-rule changes require coordinated backend and Nginx releases.
Nginx → API connections
Generated Nginx reuses HTTP/1.1 connections to the Go backend. In split deployment, frontend reuses HTTPS connections to the API server with certificate and hostname verification. These settings apply automatically after updated generated files are installed.
Each worker keeps up to 32 idle backend connections, closing idle connections after 30 seconds or after 1000 requests. This counts idle connections, rather than limiting concurrent requests. Docker DNS updates the backend address so replacing a container does not leave the old IP indefinitely.
A website alongside the CMS
If website configuration lives in the same Nginx container as the CMS, its API proxy can target http://127.0.0.1:8080 while retaining the API domain in Host. This internal listener applies the same API rules, cache, and maintenance, while avoiding an extra HTTPS connection back into its own container. Port 8080 is not published on the VPS.
A website in another container or on another server calls the public HTTPS API. Do not substitute its 127.0.0.1:8080: that points to another process. Public HTTPS and certificate verification remain enabled. Internal HTTP and public HTTPS have separate cache entries.
Finding the delay
In browser Network, inspect request timing: connection and TLS, response wait, size, and download. On the server, compare Nginx/API logs, CPU load, and database state. In load tests, compare identical routes, content, client counts, and durations; account separately for apt, backups, and server builds.
Neither these settings nor public caching alone guarantees a specific user count. If Nginx logs show worker_connections are not enough, that is a separate configuration limit; increasing it is outside this change.