# nopCommerce best practices

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`.

## Recommended optimizations

Combine nopCommerce's vendor guidance with the TurboStack options below. Most service toggles live on the host's [Services](../../platform/hosts/services.md) 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**.

> [!NOTE]
> Varnish and PHP OPcache do not apply to nopCommerce - it is a .NET application with its own internal caching, not a PHP app. Use nopCommerce's built-in caching (optionally backed by Redis) instead.

## 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](../../concepts/performance-tuning.md) 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](../../platform/hosts/backups.md) cover the SQL Server database and the application's `App_Data/` directory.
- **Watch [Health](../../platform/hosts/health.md)** - 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.

## Related

- [Deploy nopCommerce](deploy.md)
- [Troubleshooting nopCommerce](troubleshooting.md)
- [How to manage user system services](../../technologies/system-services/manage-user-services.md)
- [Services](../../platform/hosts/services.md)
- [Performance tuning](../../concepts/performance-tuning.md)