Oscar is a just a set of Django apps - it doesn’t have any special deployment
requirements. That means the excellent Django docs for deployment
should be your first stop. This page then only distills some of the experience
gained from running Oscar projects.

Setting up caching is crucial for a good performance. Oscar’s templates are
split into many partials, hence it is recommended to use the
cached template loader. Sorl also will hit your database hard if you run it
without a cache backend.

If your memory constraints are tight and you can only run one Python worker,
LocMemCache will usually outperform external cache backends due to the lower
overhead. But once you can scale beyond one worker, it might make good sense to
switch to something like memcached or redis.

Blocking in views should be avoided if possible. That is especially true for
external API calls and sending emails. Django’s pluggable email backends allow
for switching out the blocking SMTP backend to a custom non-blocking solution.
Possible options are storing emails in a database or cache for later consumption
or triggering an external worker, e.g. via django-celery.
django_post-office works nicely.

Oscar relies on the Django framework for security measures and therefore no
Oscar specific configurations with regard to security are in place. See
Django’s guidelines for security for more information.

django-secure is a nice app that comes with a few sanity checks for
deployments behind SSL.