Run the process in a scheduled container that starts each night and stops after completion, since the work runs longer than serverless allows and avoids the day-long idle baseline of an always-on dedicated server.

Migrate to a serverless function, since the platform handles all idle periods automatically and the cold start cost is negligible for any process that runs longer than a few seconds in total per invocation.

Keep the current long-running server, since predictable scheduled work performs best on infrastructure that is always available and ready to begin processing without any startup delay during the operational window.

Continue with the current server but add a second server alongside it for redundancy, since redundant capacity for a nightly batch process improves overall reliability without affecting daytime energy use.