Fix six issues preventing a fresh production install

[hdt-gif]

Deploying Engage from scratch onto a self-hosted server, I hit six issues that stop a fresh install running under settings.prod. All predate this branch and none are specific to my deployment — I think anyone standing Engage up outside NREL's own environment would meet all of them.

Happy to split this into separate PRs if you'd prefer.

Reference data has never loaded on a fresh install

compose/run-calliope-app.sh runs loaddata --app template before migrate. On an empty database those tables don't exist yet, so the load fails — and because the script has no set -e, the error prints and is ignored. The container then starts normally with no abstract technologies, no parameters and no template types, leaving an app you can't build models in.

It also only loads the template fixtures. Those reference api.Parameter and api.Abstract_Tech rows by id, and template/models.py has a pre_save hook that looks them up, so the api fixtures have to load first or the whole batch rolls back.

Fixing the order alone isn't safe, though: these fixtures carry hardcoded primary keys (admin_parameter.json is pk 1–154), and loaddata updates the row at each id rather than skipping it. Running them unconditionally on every boot would overwrite live records.

compose/seed-reference-data.sh therefore checks first — seeds an empty database, skips a populated one, and fails closed if it can't tell.

settings.prod can't start

Three independent problems:

• gunicorn is added to INSTALLED_APPS by settings/prod.py but isn't in requirements.txt, and no entrypoint invokes it
• /opt/python/log — the production logging handler writes there and nothing creates it, so Django raises at startup. batch/handlers.py already works around this with an explicit makedirs, which suggests it was known
• Static files — DEBUG=False means Django stops serving STATIC_ROOT, so the site renders unstyled. Added WhiteNoise, which avoids requiring a separate web server for single-host deployments

Broker TLS is not configurable

CELERY_BROKER_USE_SSL is hardcoded to CERT_REQUIRED. That's correct against a managed broker with transit encryption, but impossible against a plain Redis container on the same host — every worker connection fails. Now read from the environment, still defaulting to True, so existing deployments are unchanged.

Secure cookies make login impossible without HTTPS

SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE are hardcoded True. Correct behind TLS, but on a plain-HTTP instance the browser withholds the CSRF cookie entirely and every login returns "CSRF verification failed". Also read from the environment now, still defaulting to True. Adds CSRF_TRUSTED_ORIGINS.

Race condition in build_model

api/views/outputs.py sets run.run_options in memory, dispatches the Celery task, and only then calls save(). build_model re-reads the Run from the database, so a worker that starts before that save sees run_options as NULL and get_model_yaml_set fails with

TypeError: 'NoneType' object is not iterable

Timing-dependent, so it depends on the machine — builds succeeded consistently on a 4-core laptop and failed consistently on a 2-core server. Fixed by saving before dispatch.

QuerySet.first() called with an argument

compute_environment = ComputeEnvironment.objects.filter(is_default=True).first(0)

first() takes no arguments, so the fallback raises TypeError instead of returning the default environment, and the user sees "Please contact admin at engage@nrel.gov". It's the error path that's broken, which is presumably why it has survived — the UI always supplies a valid run_env, so only a request that omits it reaches this line.

createsuperuser produces an account that can't open a model

Only the registration view creates a User_Profile. An account made any other way has none, and activity.html reads

{{ comment.created|timezone:user.user_profile.timezone }}

Django's template engine silently swallows ObjectDoesNotExist, so the missing profile resolves to an empty string and the filter raises

ValueError: ZoneInfo keys must be normalized relative paths, got:

The model page then 500s for that user and works for everyone else. Since createsuperuser is the documented way to create an admin account in Getting Started, following the setup guide produces an account that can't browse models. Added a post_save receiver on User so a profile exists regardless of how the account was created.

Testing

Verified on a fresh Ubuntu 26.04 host with an empty database: reference data seeds correctly, the app starts under settings.prod with gunicorn, static files serve, both Celery workers connect, and the bundled national-scale sample model builds and solves — 36 seconds, 55 output files with plausible capacities and costs. Restore of a pg_dump into a scratch database matched row counts exactly.