nopCommerce best practices

Performance and stability best practices for nopCommerce on TurboStack - .NET runtime tuning, SQL Server, Nginx reverse proxy, caching, scheduled tasks and production mode.

nopCommerce is a .NET e-commerce platform that runs as its own long-lived process behind Nginx, rather than under PHP-FPM. A fast, stable store depends on the .NET service staying up, a healthy SQL Server connection, and the right caching and asset settings. TurboStack provisions the process management and reverse proxy for you; this page covers what is already configured and which settings to adjust.

What TurboStack configures for you

When you deploy a nopcommerce app, the platform sets up a managed .NET stack:

  • Managed application service - nopCommerce runs as a systemd user service (application.service, or <app_name>-application.service when you name the app) under your system user. It launches dotnet Nop.Web.dll from the application/ directory in your app root.
  • Automatic restarts - the service is configured with Restart=always (RestartSec=10s), so the storefront restarts automatically after a crash or a host reboot.
  • Nginx reverse proxy - a nopCommerce-specific vhost (50main.conf) proxies all traffic to the .NET process via a per-app upstream (dotnet_<user>). It uses HTTP/1.1 with keep-alive for low-latency proxying.
  • Correct proxy headers - the vhost forwards X-Forwarded-Host, X-Forwarded-For, X-Forwarded-Proto, and X-Real-IP. The service sets ASPNETCORE_FORWARDEDHEADERS_ENABLED=true so nopCommerce sees the real client IP and scheme, which is required for correct HTTPS links and security.
  • Microsoft SQL Server - nopCommerce stores its data in SQL Server (mssql_version); the connection lives in App_Data/dataSettings.json inside the application directory.
  • Environment file - runtime settings are read from a per-app conf/.env file, and the .NET runtime version is pinned with dotnet_version.

Combine nopCommerce's vendor guidance with the TurboStack options below. Most service toggles live on the host's Services tab.

  • Run in production - publish a Release build and run with ASPNETCORE_ENVIRONMENT=Production. Production disables developer diagnostics and is significantly faster than Development.
  • Enable bundling and minification - turn on JS/CSS bundling and minification in Admin > Configuration > Settings > General settings to cut request count and payload size.
  • Use a distributed cache for scale - for multi-instance or memory-pressured stores, point nopCommerce at Redis in appsettings.json instead of the default in-memory cache so cache state survives restarts.
  • Optimize images and assets - enable image resizing/caching, serve optimized (WebP) media, and keep wwwroot assets cache-friendly.
  • Front static content with a Content Delivery Network (CDN) - offload /content, /images, and theme assets to a CDN to reduce origin load and improve global latency.
  • Keep the service warm - nopCommerce has a cold start; the always-on service and automatic restarts already keep it warm, so avoid unnecessary restarts during peak hours.
  • Let scheduled tasks run - nopCommerce drives its own schedule tasks (queued emails, keep-alive, cleanup) from within the running app. Keep the service up and review Admin > System > Schedule Tasks.

Sizing and scaling

TurboStack auto-tunes resource limits from the host's size, so start with the defaults. Override tuning variables only with measured evidence (slow queries, high CPU, memory pressure):

Variable Tune when
redis_memory You enable Redis as the nopCommerce distributed cache and it evicts keys under load
SQL Server memory The database is the bottleneck on a large catalog or high order volume

Because nopCommerce uses SQL Server rather than MySQL/Elasticsearch, the MySQL and search-engine tuning variables do not apply. See Performance tuning before changing anything. When a single host can no longer handle the load, scale it up before splitting services.

Stability

  • Back up regularly - verify scheduled Backups cover the SQL Server database and the application's App_Data/ directory.
  • Watch Health - monitor CPU, memory, and disk. Confirm the application service stays running.
  • Keep versions current - track nopCommerce releases and security patches, and keep your pinned dotnet_version and mssql_version on supported releases.
  • Test on a staging clone - always trial upgrades, plugins, and theme changes on a copy before publishing to production, since plugins recompile against the running runtime.