Mökkisää

Cottage Weather Oracle now operates as: A self-hosted full-stack application A statistical weather intelligence engine A mobile-friendly web interface An automated deployment system A production-ready platform The project combines data engineering, probabilistic modelling, frontend development, infrastructure design and operational automation into a single coherent application.

Once the data was in place, the more interesting question emerged: how should the system interpret it? Several important modelling decisions were made. Daily averaging Early versions relied too heavily on isolated peaks and anomalies. A brief sunny interval could make an otherwise miserable day appear attractive. By this stage, the project had become a coherent operating system rather than a collection of scripts. The full chain was verified repeatedly: Local development Git push to Codeberg Webhook-triggered deployment Container rebuild HTTPS validation Health checks Live production updates Multiple successful deployment cycles confirmed that the system was both technically sound and operationally reliable.

Responsive design always seems simpler in theory than in practice. The mobile interface required substantial work to address: 100vh inconsistencies Safe-area issues Fixed-position overlays Scrolling constraints Layout collisions Absolute full-screen overlays were replaced with scrollable layouts, multi-column components were collapsed into single-column flows, and performance problems caused by fixed background attachments were removed. The result was a mobile experience that behaved like a proper application rather than a desktop prototype wearing a smaller hat.

Automation is useful only if mistakes are easy to undo. A rollback.sh script was introduced to restore the last known working commit. This reduced recovery from a potentially stressful debugging session to a single command. It also reinforced an important operational principle: Production is controlled, not edited directly.

Codeberg is an excellent Git hosting platform, but it does not provide the same built-in automation tools as some larger platforms. That turned out to be a feature rather than a limitation. A lightweight deployment pipeline was built from first principles: git push → Codeberg webhook → secure server endpoint → deploy.sh → Docker rebuild → live application The solution includes: A Python webhook listener Shared secret validation HTTPS protection A persistent systemd service Deploy locking Structured logs via journalctl In practice, a git push now updates the production application automatically. There is something deeply satisfying about that.

A project becomes more interesting the moment it leaves the safety of a laptop. The application was containerized using Docker and deployed to a Hetzner Cloud server running Ubuntu 24.04. The frontend runs in an Nginx container, the backend in a FastAPI container, and Caddy handles reverse proxying and automatic HTTPS via Let's Encrypt. Health checks were added to ensure that services start in the correct order and that the frontend only launches once the backend is ready. This was the point where the project moved from "works on my machine" to "works on a server, repeatedly and without drama."

At this point the project was still essentially an analytical engine. Useful, but not especially friendly. The next step was to turn it into a full web application. The backend was rebuilt as a FastAPI service exposing forecast endpoints through a REST API. The frontend was developed with React, Vite, Tailwind CSS and Framer Motion. The user interface evolved into a clean, animated experience designed to make probability feel approachable rather than intimidating.

Once the data was in place, the more interesting question emerged: how should the system interpret it? Several important modelling decisions were made. Daily averaging Early versions relied too heavily on isolated peaks and anomalies. A brief sunny interval could make an otherwise miserable day appear attractive. The model was shifted to daily averages so that the general character of the day would matter more than short-lived spikes. Regional fallback logic Not every Finnish municipality has a conveniently located weather station. When local data is missing, the system automatically constructs a regional average from nearby stations. This allows the application to provide meaningful forecasts for the entire country rather than only for well-instrumented locations. Input hardening Dates are validated carefully, and future requests are mapped to corresponding historical patterns. In other words, the model asks: what has this time of year usually been like in this location?

Every forecasting system begins with data, and weather data is rarely as tidy as one might hope. The first step was to design a SQLite database capable of storing large volumes of FMI observations while remaining lightweight and fast enough for local experimentation. The data pipeline was built to: Download and import bulk weather data Resume automatically after interruptions Remove duplicates Validate observations Normalize values for analysis This stage was not particularly glamorous, but it established the foundation on which everything else depended. As with plumbing, one tends to appreciate it most when it does not leak.