An independent project · Linux and DevOps

A web platform on Linux. From release to operations.

A website with public pages and an active community needed to become a single platform. The challenge was to bring the new interface online while retaining existing accounts, content and access. This case study covers the documented September 2026 release and the checks carried out alongside it.

I own this independent web project. This account is based on the records of the work and acceptance checks.

The context

One unified platform.

This independent web platform combines editorial content with a members-only area. The public pages and community previously had separate user journeys. The new platform brought them together in one Django application, with shared navigation and user recognition. The site's name and identifying references are omitted.

Illustrative diagram

The Linux release workflow.

Illustrative diagram of the independent Linux project: encrypted backup and isolated restore, Django release on the existing database, HTTPS acceptance checks and data checks, with code and configuration rollback prepared.

An illustration of the documented work: preparing recovery, releasing the unified platform and running checks. It does not show the production topology. The backup restore was tested in isolation; rollback to the previous code was prepared.

Open the full-resolution diagram

The constraint

Preserve what was already there.

The main constraint was the existing data. A new interface could not introduce test accounts, replace credentials or lose content. The transition also needed to handle existing sessions and retain a previous version to return to, without deleting activity recorded after the release.

The release, step by step

The documented work.

  1. Separate development from production

    Automated checks used temporary databases and simulated email delivery. The release transferred application code and assets, excluding demonstration data. The previous version was retained as a rollback point.

  2. Prepare and verify recovery

    An encrypted backup was verified before publication. The project records also document a completed restore into a temporary database, with checksum verification and media extraction, without touching production. An encrypted off-site copy was also transferred and checked.

  3. Bring the unified platform online

    The transition kept the existing database. Comparing aggregate data fingerprints before and after the release confirmed that the checked data had been preserved. Session handling was adapted to the shared platform, and the web server was reloaded after its configuration had been checked.

  4. Test the release and retain a way back

    Public acceptance checks covered HTTPS responses, layouts and browser errors. A procedure was prepared to restore the previous code and configuration without rolling back the database, preserving content added after the release.

Project acceptance checks

The recorded checks.

Documented project checks, during preparation and at release.

Before-and-after release comparisons
Data preserved

Aggregate fingerprints matched for the existing data that was checked; no demonstration data was imported.

Public HTTPS acceptance checks
13 pages

Checked with two browser engines at five viewport widths, from 320 to 1440 pixels: HTTP 200 responses, with no overflow or JavaScript/CSP errors detected.

In a temporary environment
Restore tested

Backup recovery was completed in isolation, checking checksums, the database and media without changing production.

Scope of the results

What the checks cover.

The acceptance checks describe the state observed at release. Backup recovery was tested in a temporary environment; the procedure for returning to the previous code was prepared for possible later use. The documented checks cover data integrity, application behaviour and the ability to recover.

Beyond publication

What the work leaves in place.

The work did not end when the pages went live. It delivered a unified platform, data checks, verified recovery and a documented procedure for returning to the previous code. These are considerations to address together when updating a service that people already use.

Illustration of Eddy Boscolo

The author

Eddy Boscolo.

For over 17 years, I have worked with IT infrastructure. My work covers AWS and Azure architecture, Linux administration and automation with Terraform, Ansible, Docker and Kubernetes, alongside technical teams and project managers.

Based in Vicenza, I work with businesses across Veneto and remotely throughout Italy.

The next step

Let’s discuss your project.

In a 30-minute call, we can discuss your current systems, release constraints and the checks you need.