Case study07 / 152025 – present

Launchpad

One settings file, and Launchpad sets up the server, deploys the apps and keeps watch, even on a network with no internet connection.

Role: Creator and sole developer
Organisation: Personal project, used by Ta'az (IDF)
Period: 2025 – present
Status: Generation 2 is private and still in progress

How Launchpad works: one config.json goes in, Launchpad installs the tools, prepares the environment, deploys and keeps watch, and the server ends up with the nginx web gateway, HTTPS certificates, the app services and a health check after every deploy.

Code on GitHub

01 / The challenge

Every web app has to end up running on a server. It must be installed, start by itself after a restart, answer at its web address, and be protected by a security certificate (the padlock in the browser). Done by hand, that is a long checklist, and the steps are different on Windows and on Linux.

On a closed network it is harder still: nothing can be downloaded, certificates come from an internal authority, and a mistake in the middle of an update can take a working system down with no quick way back.

A long manual checklist for every server
Different steps on Windows and on Linux
Nothing can be downloaded on a closed network
A failed update could leave a site down

02 / What I built

Launchpad reads one settings file (config.json) that answers seven plain questions: which system, which kind of deployment, which tools and where they come from, how to prepare the environment, which apps to run, and which certificates they use. From that file it installs the tools, sets up each app as a service that starts by itself, configures the nginx web gateway (the front door that sends each web address to the right app) and gets the certificates. The same file works on Windows and on Linux.

Operators work from a simple menu, and every action is also a command for automation. Every deploy is guarded: before touching anything Launchpad checks for conflicts, after the deploy it asks each app whether it really answers, and if one does not, it puts the previous version back.

How it came together

Apr 2025First public releaseMenu-driven scripts that deploy one app on a Windows or Linux server, published on GitHub.
Jul 2025Many apps, one serverManages apps by domain, subdomain or sub-path. Named Launchpad, with four guides and an MIT licence.
Nov 2025Settings move to filesJSON settings files replaced the list of apps that had been written inside the scripts.
Dec 2025Planning generation 2A written spec for closed networks, several servers and premade certificates.
Jun 2026Rebuilt with Claude CodeOne Python engine for Windows and Linux, built with Claude Code. An audit against the old scripts fixed 33 gaps.
Jul 2026Ready for productionFive hardening phases, each re-audited by AI review agents. 310 automated tests, run on Windows and Linux.
Aug 2026Ta'az production server installedLaunchpad set up the platform's production server from one settings file and one package, with no internet connection.

03 / Highlights

One file describes the server

Which tools to install, which apps to run, at which addresses and with which certificates: all in one settings file, the same on Windows and Linux.

Works on closed networks

Tools and Python packages come from a local bundle, and certificates are made locally or issued internally. Nothing is downloaded on the server.

Safe updates that undo themselves

Checks for conflicts before it changes anything, confirms every app really answers afterwards, and if an update fails, the previous version comes back by itself.

Secure addresses, hands-off

Gets the certificates that make each web address secure, on the internet or on an internal network, and renews them before they expire.

Keeps watch after deploying

A scheduled check spots a stopped service, an expiring certificate or changed settings. It alerts and, if allowed, fixes them within safety limits.

AI-assisted engineering

Built with Claude Code to my design and phase plan. AI reviewers checked every phase again, and automatic tests must pass before any change goes in.

04 / Screens

11 screens

Illustration of the generation-2 menu: the Launchpad banner, the header "acme v3.0.0 · env: production · windows/native" and the nine menu items; next to it the service picker and the menu for the web service, with Start, Stop, Restart, Status, Logs, Update, View nginx config, Uninstall and the app's own actions — 01 Illustration of the real menu. Left: the main menu, whose live header shows the project, version, environment and platform. Right: "Manage a service" for one app, with the usual lifecycle actions and the app's own actions (run database migrations, rebuild the search index, open an app shell).

The deploy pipeline in five steps with its two outcomes, and two terminal excerpts: a pre-flight that aborted because port 7700 was taken, and a failed health check that was rolled back — 02 Safe by design: every deploy runs the same five steps. The terminal excerpts are the tool's real messages: a pre-flight that stopped before touching anything, and a new version that did not answer and was replaced by the previous one.

The Ta'az platform deployment: an offline release bundle with config.json, 13 installers, wheels and apps goes through bootstrap, env-setup and deploy to a Windows production server, where nginx serves three HTTPS addresses for the portal, its admin site and the file and media service (CDN), next to two internal services — 03 Installing the Ta'az production server (August 2026), drawn from the platform's own Launchpad config: an offline release bundle is installed on the Windows production server with NSSM services and existing certificates. nginx serves three HTTPS addresses: the portal site and its API, the content-management site, and the file and media service (CDN) and its API. Next to them run an internal notifications service and a search engine. Operators run the apps' own actions from the menu.

Side-by-side comparison of generation 1 and generation 2 on eight rows: code, settings, what it runs, safety, certificates, closed networks, after the deploy and quality — 04 From scripts to an engine: what changed between the two generations. Generation 2 was built with Claude Code.

Code excerpts: on the left, the list of apps hard-coded in the Windows script and again in the Linux script; on the right, one declarative service in config.json — 05 How apps were described, then and now: in 2025 the app list lived inside each script; in 2026 one declarative config.json describes a service, its routes and its certificate.

The day-2 control plane: a scheduled tick runs one bounded pass that observes, acts and records, with four brakes on self-healing — 06 After the deploy: a scheduled pass, every five minutes by default, checks health, nginx, certificate expiry and drift, renews certificates and records everything. Self-healing is opt-in and has four brakes: debounce, cooldown, a circuit breaker and a cap on actions per pass.

The offline bundle layout and five cards showing the offline path for server tools, Python packages, certificates, container images and Launchpad itself — 07 Built for closed networks: the offline bundle layout from the project's documentation, and how each need is met without a network.

Quality evidence: 310 automated tests, 9 of 9 CI jobs green, and the list of CI jobs on Ubuntu and Windows — 08 Tested on real machines: every change runs lint, type and coverage gates, unit tests on Windows and Linux with two Python versions, integration tests that install nginx, systemd and NSSM for real, and packaging checks.

How generation 2 was built: I set the design, Claude Code builds, AI agents re-audit each phase, tests and CI gate each change and I merge; the result installed the Ta'az production server in August 2026 — 09 AI-assisted, human-directed engineering: I wrote the specs and the phase plan, Claude Code wrote the code (84 of the 86 commits carry its co-author line), AI review agents re-audited every phase, and 310 tests and 9 of 9 CI jobs decided what I merged.

Illustration of python launchpad.py --help with 18 subcommands and the global options — 10 Illustration of the command-line help: 18 subcommands, from status and deploy to backup, restore, reconcile and audit. The help text is taken from the tool's own code.

Two-generation timeline: April 2025 first public release, July 2025 multi-app manager, November 2025 settings files, December 2025 next-generation plan; June 2026 rebuilt with Claude Code, July 2026 production-ready, August 2026 installed the Ta'az production server — 11 The two generations of Launchpad, from public scripts to the engine that installed the Ta'az production server.

05 / Impact

6servers set up

Under 15 minto set up a server, instead of more than 5 hours by hand

1settings file and one package set up the Ta'az production server in Aug 2026, on a network with no internet connection

2operating systems, Windows and Linux, from the same settings file

Launchpad turned setting up a server from a long manual checklist into one repeatable process. Across both generations it set up 6 servers on 4 separate networks and deployed 20–25 apps and services, about 50 releases in all. It was an internal tool for my team at Ta'az and for my own servers. A server that took more than 5 hours to set up by hand took under 15 minutes with Launchpad.

In August 2026 the second generation installed the Ta'az platform's production server: five services, three secure web addresses and 13 server tools, all from one settings file and one package, on a network with no internet connection. Before that, a first-generation Windows script ran the platform's apps there. With Claude Code, generation 2 was written in three working days, and every phase was checked again and tested before I merged it.

06 / Role and tech

I created Launchpad and built both generations: the idea, the design of the settings file, the code for Windows and Linux, the documentation and the tests. In 2025 I wrote and published the first generation and used it to host my own web apps. In June 2026 I built a deploy engine inside the Ta'az platform's code, extracted it into a standalone tool that can deploy any project, and hardened it in five phases. In August 2026 it installed the platform's production server.

I built generation 2 with Claude Code as my coding agent: 84 of its 86 commits are co-authored by it. I wrote the specs and the phase plan, had AI review agents re-audit every phase, kept tests and CI as hard gates, and merged each change myself. The AI made the work faster; the decisions and the result are mine. Generation 2 is private and still in progress.

Tech

Python (standard library)
nginx
NSSM
systemd
Docker / Podman compose
Let's Encrypt / Certbot
OpenSSL
JSON Schema
pytest
GitHub Actions
Batch / Bash (generation 1)
Claude Code
Waitress
Gunicorn
ruff
mypy
Gemini

How it's built

The first generation was written in Windows Batch and Linux Bash: two parallel menu scripts built on nginx, NSSM or systemd, Waitress or Gunicorn, and Certbot. The second generation is one Python package that uses only the standard library, so it can be copied onto an offline server and run. It has a separate layer for each system (NSSM on Windows, systemd on Linux, Docker or Podman compose), a JSON Schema for the settings file, 310 automated tests, and a GitHub Actions pipeline that installs nginx, systemd and NSSM for real. I built it with Claude Code working to my specs and phase plan; multi-agent reviews re-audited every phase before I merged it, and the project ships a Claude Code skill for writing deployment settings. Certificates come from Let's Encrypt on the internet, or are existing or self-signed certificates on internal networks.

Code on GitHub

Launchpad grew from scripts I wrote for my own apps into the engine that installed a production server, built fast with Claude Code while I led, checked and owned the result.