Oploy Notes

My old laptop became a Linux server

Tue, 01 Sep 2026 00:00:00 GMT

I had an older Huawei laptop with 8 GB of RAM and a Core i5 processor. I installed Ubuntu Server on it, and gradually moved useful services onto it. It now stays on day and night while I work from my Windows laptop.

I started this setup in September 2026. The service inventory and RAM measurements below were checked in October 2026.

There was no big plan to build a home data centre. I wanted to see how much useful work a computer I already owned could do.

What actually runs on it

The processor is an Intel Core i5-10210U, with four cores and eight threads. Ubuntu reports about 7.5 GiB of usable RAM. On 8 October 2026, the machine had been up for 28 days and nine hours, with 28 running Docker containers.

Here is one RAM snapshot, taken at about 23:36 Amsterdam time that evening. Each application row includes its supporting containers, including its database where applicable. MiB means mebibytes.

Service	Public address	What I use it for	RAM in this snapshot
Oploy website	www.oploy.eu	Django/Wagtail website and PostgreSQL	147 MiB
Oploy Notes	notes.oploy.eu	This static notebook, served by nginx	8 MiB
JobLab	or.oploy.eu/dashboard	Operations research job dashboard, PostgreSQL, PostgREST and API proxy	198 MiB
AI engineering jobs	aieng.oploy.eu/dashboard	AI, ML and data science job dashboard and its own database stack	163 MiB
Lang App	lang.oploy.eu	Language learning, audio processing, API, web app, PostgreSQL, Redis and proxy	681 MiB
JobPilot personal search backend	JobPilot My Job Search API: jobsearch-api.oploy.eu/health	Search API, PostgreSQL, PostgREST and proxy	170 MiB
Inventory simulation	siminv.netlify.app API: api-siminv.oploy.eu/health	Run inventory simulations	18 MiB
Inventory optimization	simopt.netlify.app API: api-simopt.oploy.eu/health	Search for inventory policies using simulation	50 MiB
Repair-shop scheduling	opt.oploy.eu API: api-scheduling.oploy.eu	Optimization API for scheduling experiments	70 MiB
Self-hosted Convex stack	Used by JobPilot	Backend, database and dashboard; JobPilot’s frontend is hosted elsewhere	693 MiB
Portainer	Private administration	Manage Docker containers, logs, images and volumes	21 MiB

For the three optimization projects and JobPilot, the website itself is hosted elsewhere (Netlify for the optimization apps). The laptop runs the API behind it, which is why each row has two links.

The scraper runs on a schedule, so its temporary container is not included in these always-running figures. Cloudflare Tunnel is a host service and used about 42 MiB of resident memory separately.

These are observed use, not memory limits or peak requirements. Audio work, scraping and optimization can need much more. The language worker was active during the measurement, so this is not a strict idle benchmark.

The host reported about 3.2 GiB used and 4.3 GiB available, with about 0.82 GiB in swap. Linux also uses RAM for caches. Container figures do not add up to the whole operating system’s memory use.

A separate place to run things

One benefit is simple: I can close my Windows laptop and the services keep running. My working computer and the server have different jobs.

Docker gives each application its own dependencies, network and persistent storage. A Python virtual environment is also useful for a small script. I can try a deployment without filling my Windows machine with another database and another background process.

This is the separation I wanted from a virtual environment. Containers share the Linux kernel; they are not full virtual machines. An experiment can still exhaust the host unless I set limits. For stronger isolation, I would use a VM and budget extra RAM for it.

Ubuntu Server does not run a desktop interface on this machine. That leaves more room for the services, but I did not measure the same workload on Windows before the move, so I cannot give an honest RAM-saving percentage.

It feels responsive for my small workloads. A recorded language-app test processed a roughly three-minute audio fixture in about 28 seconds with four CPU threads. That is one specific test, not a promise that an older laptop can handle every AI workload.

Managing it from Windows

Most of the time I open Windows Terminal, connect over SSH and deploy there. I build an image, start a container, read its logs and check its health endpoint. I do not need to sit at the server’s keyboard.

For a visual overview, I use Cockpit for the operating system and Portainer for Docker. Seeing memory, logs and services in a browser makes small problems easier to understand.

I also added two Cockpit pages for the laptop hardware:

Battery: charge percentage, AC connection, battery health, cycle count and current power draw. It refreshes every five seconds while visible.
Display: brightness, screen on/off and the font size on the physical console. These controls need administrative access.

Battery monitoring and charging control are separate. A boot service applies charging thresholds: start below 75%, stop at 80%. The live reading was 79%, with the battery not charging. The dashboard makes the state visible; it does not enforce those thresholds.

I also changed lid and power-button behaviour, and added a lid hook that blanks the display without suspending the server. A third-party Docker Manager page gives me basic container controls inside Cockpit. Portainer remains useful for deeper management.

Moving services from Railway and AWS

I moved the Wagtail website and its PostgreSQL database from Railway on 11 September 2026. The application runs locally in Docker, and visitors reach it through Cloudflare Tunnel. Website media still lives in Cloudflare R2.

The earlier Railway database note describes the setup I moved from.

For JobLab, a systemd timer took over the scheduled scraper job from AWS. Its data now goes through duplicate checks into local PostgreSQL and the dashboard. The deployment record says the AWS schedule was disabled after verification.

I described the original cloud version in the AWS Fargate scraper note.

JobPilot’s personal search backend also moved from Lambda to the server. That required adapting the application and changing frontend endpoints. Moving from serverless hosting involves more than copying a function file.

I did not move every cloud dependency. This is a mixture of local services and external services, which suits me better than making everything local just for the sake of it.

What went wrong, and what I still have to own

Closing a lid must not suspend a server. The default short power-button press also shut this machine down unexpectedly, so I changed it. Keeping the screen dark and leaving the cooling vents clear matter too.

The battery limit was another lesson. The Huawei driver showed the thresholds I had written, but firmware smart-charge mode initially ignored them. I had to verify actual charging behaviour rather than trust a setting that looked correct.

I reused hardware, so the additional hardware cost was zero. Electricity, storage, backups, domain fees, external APIs and my maintenance time still count. I have not measured total monthly savings against AWS and Railway.

Running 24 hours a day is my operating choice, not an availability guarantee. Internet outages, a failed disk or a stopped tunnel can take these applications offline. The battery can keep the laptop alive briefly; it cannot keep the building’s router online.

For small applications and learning, I am happy with this tradeoff. For something that needs stronger availability, I would choose hosting that matches that requirement.

How to repeat this

I wrote a separate step-by-step guide covering installation, Windows SSH access, a first Docker service, migration, and the Cockpit additions. Screenshots of the laptop and dashboard can follow later.

If you have a spare laptop, try one small service first. Check its memory, leave it running, and learn how to restore it. You do not have to move everything to find out whether this is useful for you.

How to turn a spare laptop into a Linux server

Tue, 01 Sep 2026 00:00:00 GMT

My experience note describes what runs on my 8 GB Core i5 laptop. This guide explains how to build a similar setup, starting with one service and adding the laptop-specific pieces afterward.

The commands below are examples for a fresh Ubuntu Server 24.04 installation. Replace the username, address, domain and application paths with your own. Hardware-specific steps need checking on your laptop.

1. Prepare the laptop

Back up the files you want to keep before installing Linux. Installation can erase the selected disk. I used the server edition of Ubuntu without a desktop interface.

Download the installation image (ISO) from the official Ubuntu Server website. My setup uses Ubuntu Server 24.04 LTS. To follow the same version, look under previous releases if the main download button offers a newer release.

I used Rufus on Windows to prepare a hard disk as bootable installation media. It worked, but for a first attempt I would use a USB flash drive. It makes it easier to keep the installer separate from the laptop’s disk where Ubuntu will be installed.

In Rufus, select the drive you intend to use as installation media, choose the downloaded ISO, and write the image. Preparing that drive can erase its contents, so check the selected device carefully. Then boot the laptop from that drive using its boot menu and follow the Ubuntu installer.

My installation was not completely smooth. I ran into errors while choosing file locations and a few other setup problems. I worked through them and had them resolved within a day. If your first attempt needs some troubleshooting, that does not mean you cannot do this. Take one problem at a time, and double-check the selected disk before confirming storage changes.

Use a working charger, sound battery and ventilated surface. A swollen battery needs replacing before continuous use. Ethernet is useful if available; mine uses Wi-Fi, which adds another dependency to availability.

During installation, create a normal user and select OpenSSH server. Once the machine has network access, check it at the physical keyboard:

ip -br address
lscpu
free -h
df -h
sudo apt update
sudo apt upgrade

If OpenSSH was not installed:

sudo apt install openssh-server
sudo systemctl enable --now ssh

Ubuntu documents the installation and configuration in its OpenSSH server guide.

2. Connect from Windows Terminal

In PowerShell, use the address shown on the Ubuntu laptop:

ssh your-user@YOUR_SERVER_ADDRESS

On the first connection, compare the host-key fingerprint with the server before accepting it. You can display the server’s ED25519 fingerprint at its own keyboard:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Create a Windows SSH key if you do not already have one. Keep the private key on Windows; only its .pub file goes to the server. A passphrase protects the key if the file is copied.

ssh-keygen -t ed25519
Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" | ssh your-user@YOUR_SERVER_ADDRESS "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"
ssh your-user@YOUR_SERVER_ADDRESS

For a shorter command, add an entry to your Windows user SSH config, ~/.ssh/config:

Host spare-server
    HostName YOUR_SERVER_ADDRESS
    User your-user
    IdentityFile ~/.ssh/id_ed25519

Then ssh spare-server opens the Linux terminal. The server keeps running when that terminal closes. A DHCP reservation helps keep its address stable if you control the router.

3. Keep the laptop awake

On Ubuntu, create a logind drop-in rather than modifying the main configuration file:

sudo mkdir -p /etc/systemd/logind.conf.d
sudo tee /etc/systemd/logind.conf.d/10-laptop-server.conf >/dev/null <<'EOF'
[Login]
HandlePowerKey=ignore
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
EOF
sudo systemctl reload systemd-logind

Check the effective setting:

busctl get-property org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager HandleLidSwitch

It should report ignore. Close the lid and confirm that SSH still works. Keep the vents clear; some laptops cool poorly with the lid closed. Shut down deliberately with sudo systemctl poweroff.

My own configuration also requests a clean shutdown on a long power-button press. Firmware can cut power before the software reacts, so I do not rely on that as a safe shutdown method.

Ignoring the lid does not necessarily turn the panel off. My separate acpid hook reads the lid state and writes the panel’s bl_power setting. The screen behaviour depends on hardware, so test screen control separately before automating it.

4. Install Docker and run one service

Follow Docker’s Ubuntu installation guide to add its signed APT repository. After that repository is configured:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo docker run --rm hello-world
sudo docker compose version

Here is a small first service. On the server, create ~/first-service/compose.yaml:

services:
  web:
    image: nginx:stable-alpine
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    mem_limit: 128m
    cpus: 0.5
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Start and check it from that directory:

sudo docker compose up -d
curl -I http://127.0.0.1:8080
sudo docker compose logs --tail=30
sudo docker stats --no-stream

The loopback binding keeps the example off the LAN. From Windows, forward it through SSH:

ssh -N -L 8080:127.0.0.1:8080 spare-server

While that connection stays open, visit http://localhost:8080 in your Windows browser. You should see nginx’s welcome page. The image tag follows a release channel; pin a tested digest when you need a reproducible deployment.

For a real app, replace the image, add the correct environment and health check, and give databases named volumes. Set memory limits based on measured peaks. Several 2 GiB limits do not mean the host has enough RAM to satisfy them simultaneously.

5. Give a service a public address

I use Cloudflare Tunnel, which connects outward from the server. I did not need an inbound router port-forward for the website. A tunnel provides the route; the application still needs its own authentication where appropriate.

Follow Cloudflare’s locally managed tunnel instructions to install cloudflared, log in, create a tunnel and protect its credential file. My deployment uses local configuration; Cloudflare also offers remotely managed tunnels.

For a fresh named tunnel, the creation commands are:

cloudflared tunnel login
cloudflared tunnel create spare-server

An illustrative configuration is:

tunnel: YOUR_TUNNEL_ID
credentials-file: /etc/cloudflared/YOUR_TUNNEL_ID.json
ingress:
  - hostname: demo.example.com
    service: http://127.0.0.1:8080
  - service: http_status:404

The credential path must match where you securely installed the generated file. Add the hostname under a domain you control:

cloudflared tunnel route dns spare-server demo.example.com
sudo cloudflared tunnel --config /etc/cloudflared/config.yml ingress validate
sudo cloudflared --config /etc/cloudflared/config.yml service install
sudo systemctl enable --now cloudflared

These service-install commands are for a new setup. An existing tunnel should be backed up and edited without reinstalling its service. Test the local endpoint first, then the public hostname. Cloudflare explains rule order and the final catch-all in its configuration reference.

6. Add Cockpit and the laptop pages

Cockpit gives me system metrics, services, logs, storage and a terminal. On my Ubuntu 24.04 server I installed individual components from backports:

sudo apt install -t noble-backports cockpit-bridge cockpit-ws cockpit-system cockpit-storaged pcp
sudo systemctl enable --now cockpit.socket
sudo systemctl enable --now pmcd pmlogger

This assumes the noble-backports repository is enabled. I avoided adding Cockpit’s NetworkManager component because this machine already uses netplan with systemd-networkd for Wi-Fi. Check the package changes before accepting them on a machine managed over SSH.

Keep administration on a trusted network or VPN. You can also forward Cockpit from Windows with ssh -N -L 9090:127.0.0.1:9090 spare-server and open https://localhost:9090. Its default certificate is self-signed; verify the server identity before trusting it. The forward does not itself restrict the server’s listening socket.

The Battery page

I included the actual source files from my server with this guide:

Save all five together in ~/cockpit-battery on your server, review the files, then run:

sh ~/cockpit-battery/install.sh
cockpit-bridge --packages

The script copies the package to /usr/share/cockpit/battery/. Reload the Cockpit browser session; if necessary, sign out and back in. You should see Battery in the menu.

It reads /sys/class/power_supply/ without elevated privileges. It finds devices by their type instead of assuming BAT0, supports both energy_* and charge_* readings, and pauses its five-second polling while hidden. It uses design voltage to convert charge capacity to watt-hours when available.

The Display page

The matching files are manifest, HTML, JavaScript, CSS and installer. Save them in ~/cockpit-display.

Adapt display.js before installing it. My version uses intel_backlight, /dev/tty1, and Uni2-TerminusBold console fonts. Check your backlight directory and available font files:

ls /sys/class/backlight
ls /usr/share/consolefonts/Uni2-TerminusBold*

Change BRIGHTNESS_PATH, MAXB_PATH, BLPOWER_PATH, TTY, FONT_PREFIX and FONT_SIZES as needed. The page reads the actual maximum brightness, so it does not assume a 0–255 range. Then run sh ~/cockpit-display/install.sh and reload Cockpit.

Display writes require Cockpit’s administrative access. One detail cost me time: cockpit.spawn() takes process input through .input(), rather than an input option:

var proc = cockpit.spawn(["tee", path], {
    superuser: "require",
    err: "message"
});
proc.input(value);
return proc;

For sysfs, use a direct write like this. A temporary-file-and-rename operation cannot replace a sysfs attribute. Cockpit documents packages and process spawning.

I also use Portainer and a third-party Docker Manager plugin for container management. Docker Manager is optional. Access to Docker or its socket gives extensive control of the host, so these belong behind restricted administration access.

7. Configure battery charging separately

My Battery page monitors; it does not set limits. A separate boot service applies 75% start and 80% stop thresholds through Huawei’s driver.

Inspect the interfaces your hardware exposes:

ls /sys/class/power_supply
find -L /sys/class/power_supply/ -maxdepth 2 -name '*threshold*'

On my supported Huawei model, the paired attribute exists at the following path:

cat /sys/devices/platform/huawei-wmi/charge_control_thresholds
printf '75 80\n' | sudo tee /sys/devices/platform/huawei-wmi/charge_control_thresholds

This is a Huawei-specific example, not a command for every laptop. Check your driver’s documentation and firmware first. Make a persistent boot service only after a manual test works.

On my machine, smart-charge firmware initially ignored these settings even though the driver read them back correctly. My boot script disables that mode before applying the pair. The Huawei WMI project describes that hardware-specific behaviour; do not copy its low-level firmware calls to an unrelated model.

Watch the charge percentage, AC state and current over time, then verify again after a reboot. Reading back 75 80 alone does not prove the battery obeys it. Mine can say “Not charging” or “Discharging” on mains while above the charging range.

8. Move one cloud application at a time

Before cutting over, list the code, database, uploaded files, secrets, scheduled tasks, domain routes and external APIs. Recreate each dependency or deliberately keep it hosted. An application image does not contain its database volume.

Previous component	My local replacement	What needs checking
Railway Wagtail application	Docker application container	Settings, allowed hosts, migrations, secrets and local health
Railway PostgreSQL	PostgreSQL container and named volume	Compatible version, dump/restore, data and permissions
AWS scheduled scraper	Docker job started by a systemd timer	Timezone, duplicate checks, logs and successful writes
Lambda personal search	FastAPI service and supporting database stack	Request contract, authentication, timeouts and frontend endpoints
Public cloud endpoint	Cloudflare hostname routed to local loopback port	Public response, login and application behaviour

Railway: app and database together

My Wagtail move used pg_dump -Fc and pg_restore, with PostgreSQL 16 on both sides. I checked page counts and the latest publication timestamp before routing the public domain to the laptop.

My Railway PostgreSQL note shows the original application connection and settings.

For your own move, stop application writes for the final dump, or use a replication strategy. Restore into the local database, apply the app’s required migrations, and test through a temporary route or SSH forward. Keep credentials out of shell history and committed files.

Check TLS settings too. My app previously forced database SSL for Railway; the local database did not provide that SSL listener. I changed that setting only for the container-local connection. Public traffic remains HTTPS through Cloudflare.

Keep the old deployment until the cutover is verified. Once the local database accepts new writes, the old database becomes stale: rollback needs a plan for those writes, not just a DNS change.

AWS: replace schedules and execution assumptions

For a scheduled job, use a oneshot systemd service that runs the scraper container, plus a timer. An illustrative timer is:

[Unit]
Description=Daily scraper schedule

[Timer]
OnCalendar=*-*-* 02:00:00 Europe/Amsterdam
Persistent=true
Unit=my-scraper.service

[Install]
WantedBy=timers.target

This needs a matching my-scraper.service with the correct working directory and container command. Persistent=true catches up a missed run when the timer becomes active again. Check the timezone and next run rather than assuming it matches the old cloud schedule.

Verify one local run, its database writes and duplicate handling before enabling the timer and disabling the old AWS schedule. Do not leave two writers running unintentionally. My JobLab scraper uses local PostgreSQL; an earlier hosted-upload configuration was corrected and is not the current route.

For Lambda, adapt the event handler into an HTTP application, or use an appropriate adapter. Replace IAM-role assumptions, keep external cloud APIs explicitly configured, and check timeouts, concurrency and access control. My personal-search deployment still had an unauthenticated search endpoint in its deployment record, so I would add authentication and rate limits before recommending that pattern for another public service.

9. Keep it recoverable

My regular checks are small:

free -h
df -h
sudo docker stats --no-stream
sudo docker compose ps
sudo docker compose logs --tail=50
systemctl list-timers --all
sudo journalctl -u cloudflared -n 30

Run the Compose commands inside the relevant application directory. Look at available memory, swap activity, disk space and the last successful scheduled job. A running container is not proof that its application is healthy.

Use database-aware backups, keep a copy off this laptop and practise a restore into a separate database. Some of my stacks have nightly backups, but a backup on the same disk does not protect against losing that disk. Retain working application releases and record how to restore their matching database state.

Test restart behaviour during planned maintenance, with backups and physical access available. Check Docker, the tunnel, timers and actual public endpoints afterward. Avoid rebooting a production host just to demonstrate a guide.

Restrict SSH and dashboards. Docker’s published ports can bypass ordinary UFW rules, as its firewall documentation explains. My loopback-bound public application ports are reached through the tunnel, but administration access needs its own restrictions.

How to repeat this

Start with Ubuntu, a working SSH connection and the nginx example. Once you can start it, inspect it and bring it back after a planned restart, move one small application with a tested backup.

Add the Battery page first because it only reads hardware state. Add Display and charging control after checking your laptop’s interfaces. The server does not need every feature on day one.

What went wrong

My useful lessons were mundane: the short power-button press shut the server down, battery thresholds looked correct but were ignored, and the Display page stalled because process input was passed the wrong way. Another migration briefly used the wrong database destination.

Those mistakes made me check effective settings, charging behaviour and actual writes. If you try this, keep a short record of what you changed and how you verified it. That record is often more useful than another dashboard.

Building JobLab on AWS Fargate

Tue, 18 Aug 2026 00:00:00 GMT

Written in August 2026. Job totals and costs below are snapshots from then.

Start with the deployed result: explore the live JobLab dashboard. Then return here for the code path that produces it.

The dashboard is the observable output of a daily data build. Its charts query standardized records rather than raw scraped pages. A posting passes through source collection, cleaning, taxonomy mapping, skill and tool extraction, an S3 snapshot, a Supabase upsert, and database deduplication before it appears in the interface.

The totals in these screenshots are snapshots because each scheduled run can add or remove records. Use the live dashboard for the current dataset, and use the repository to understand how each field was produced.

My instance uses optimization-specific retrieval rules

The pipeline is reusable, but this deployed instance reflects my own search. In 1- Scrapped Data/job_scraper.py, FILTER_KEYWORDS_TITLE casts a broad net with terms such as optim, operations research, supply chain, routing, scheduling, decision science, data scientist, and solver.

FILTER_KEYWORDS_STRONG then checks descriptions for higher-precision terms such as linear programming, mixed integer, MILP, Gurobi, CPLEX, OR-Tools, Pyomo, vehicle routing, stochastic optimization, and demand planning. FILTER_KEYWORDS_NEGATIVE rejects title matches for unrelated uses such as SEO, sales optimization, and marketing optimization.

These are my domain choices, not built-in JobLab requirements. To build another instance, replace the title, strong, and negative keyword lists; update src/config/skills_reference.json and src/config/tools_reference.json; then review the taxonomy mappings in 3- Enrichment + Standardization/taxonomy_standardization.py.

One container runs the complete daily build

EventBridge starts an ECS Fargate Spot task at 02:00 UTC. The container entrypoint is src/orchestrate/run_weekly.py. It creates fresh stage databases, runs the scraper, preprocessing, and enrichment scripts as subprocesses, uploads an atomic snapshot to S3, upserts normalized rows through the Supabase REST API, removes duplicates, records stage counts, and exits.

Runtime behavior comes from environment variables such as SCRAPE_COUNTRIES, SCRAPE_MAX_JOBS, DAYS_BACK, S3_BUCKET, SUPABASE_URL, and DRY_RUN. AWS credentials and service keys are supplied through SSM Parameter Store. Terraform provisions ECR, ECS, IAM, CloudWatch Logs, the schedule, and the task definition.

One scheduled container, three downstream consumers.

Inspect each deployable component on GitHub

JobLab is split by runtime responsibility. The repositories below contain the source and configuration discussed here.

Daily data pipeline: Inspect the six-stage Python pipeline, SQLite stage files, relevance filters, skill and tool vocabularies, Supabase exporter, Docker image, Terraform, and scheduled Fargate task. This is where you replace my optimization-specific retrieval rules.
Analytics dashboard: Inspect the Next.js, TypeScript, Mantine, ECharts, Zustand, and Supabase frontend that turns standardized records into linked filters, charts, heatmaps, and job-level results. I wrote it up in building the JobLab analytics frontend.
AI agent API: Inspect the FastAPI and Mangum API on AWS Lambda, the Bedrock tool-calling loop, structured and semantic retrieval, CV matching, MLflow traces, evaluation, and prompt optimization. The tracking server is described in deploying MLflow on Railway.
Lakehouse version: the same dataset as a PySpark Bronze, Silver and Gold pipeline, reproduced in Databricks Delta Lake.

Build analytical fields from noisy text

Job titles alone are unreliable. A relevant role may be called Decision Scientist, Supply Chain Analyst, or Applied Scientist. The enrichment stage assigns standardized job function and industry values, detects language and education signals, and extracts skills and optimization tools from the description.

The controlled vocabularies live in src/config/skills_reference.json and src/config/tools_reference.json. Extraction code under src/analysis/skill_extraction/ keeps tools such as Gurobi, Pyomo, OR-Tools, and CPLEX separate from general skills. The dashboard can then group records consistently while preserving the original title and description for verification.

Validate aggregates against source records

The time series and country-by-function heatmap are useful because both respond to the same filter state. When a group changes unexpectedly, I can drill into its postings and check the original source, title, taxonomy, and extracted terms. This turns the frontend into a data-quality tool as well as a presentation layer.

Inspect the current trends in JobLab.

Match the compute model to the workload

The table is a snapshot of my AWS bill for June 2026. It is not a fixed monthly price, and it will change with workload and AWS pricing.

Service	June 2026
Elastic Container Service (Fargate Spot)	$0.36
Virtual Private Cloud	$0.04
Other	$0.15
Total	$0.55

The batch runs for a few minutes and exits, so an always-on server would waste idle compute. Fargate runs the scheduled container, Lambda handles request-response AI traffic, and the frontend is deployed separately. Each component uses a runtime suited to its execution pattern.

Infrastructure work is larger than the compute bill

The first deployment required an ECR repository, image build and push, ECS cluster and task definition, execution and task IAM roles, CloudWatch log group, SSM parameters, networking, and an EventBridge schedule. Terraform makes those resources reproducible, but it does not remove the need to understand their permissions and failure modes.

Secrets belong in SSM Parameter Store and deployment environments. After terraform apply and the image deployment, scripts/run-manual.sh can trigger a test task and aws logs tail /ecs/joblab-pipeline --follow can verify every stage before the daily schedule is trusted.

Reuse the right level

Use JobLab Analytics to inspect my deployed optimization-focused instance. Use JobPilot My Job Search (sign-in required) when you want a personal search with your own keywords and no infrastructure deployment. Fork the data-pipeline repository when you need control over sources, countries, relevance rules, taxonomies, storage, and scheduling.

How to repeat this

Fork joblab-data-pipeline.
Replace the three keyword lists in 1- Scrapped Data/job_scraper.py and the vocabularies in src/config/skills_reference.json and src/config/tools_reference.json.
Put AWS credentials and service keys in SSM Parameter Store, never in the repository.
Run terraform apply, then build and push the image to ECR.
Trigger one task by hand with scripts/run-manual.sh and follow its logs:

aws logs tail /ecs/joblab-pipeline --follow

Only trust the 02:00 UTC schedule after one manual run has passed every stage.

One thing to check first: terraform/variables.tf names the log group /ecs/joblab-pipeline, while scripts/run-manual.sh prints /ecs/joblab. Use the name Terraform created.

For a smaller service on a simpler platform, see how I deployed FastAPI on Railway.

Building JobPilot's Technical Architecture

Sun, 19 Apr 2026 00:00:00 GMT

Written in April 2026.

JobPilot is a multi-service application rather than a single prompt wrapped in a user interface. I built the main application with SvelteKit, store reactive task state in Convex, run personal job retrieval through a separate FastAPI service, persist search data in Supabase Postgres, and use Gmail signals to update the application board.

The technical design follows one rule: search results, imported job descriptions, generated documents, and email outcomes must all resolve to the same structured task record.

System boundaries and data flow

SvelteKit owns pages and server routes. Convex owns user-scoped application state and orchestration. The Python service owns scraping, normalization, deduplication, and ranking. Supabase stores search profiles, runs, canonical jobs, and matches. This separation keeps a slow search run or external API failure away from the interactive task-board runtime.

1. Personal search as a separate service

The My Job Search page sends user-owned keywords, location, country, date window, source selection, and remote preference through src/routes/api/personal-search/+server.ts. Keyword suggestions are handled separately in suggest-keywords/+server.ts, and send-to-tasks/+server.ts converts selected results into application tasks.

The backend performs scraping, normalization, deduplication, ranking, and selective enrichment before writing structured results to Supabase. Unlike JobLab, this instance is not locked to my optimization search. Each user supplies their own terms in My Job Search, or derives them from a CV profile, without redeploying the shared service.

Watch the video walkthrough on YouTube

2. Normalize every job into one task schema

A job can enter from pasted text, a URL, a company page, or a personal search result. src/lib/convex/todo/jobInput.ts normalizes those inputs before the task agent works on them, and the task fields are defined in src/lib/convex/schema.ts. Role, company, source URL, description, status, and generated artifacts therefore stay attached to one record.

Whatever the source, the result is the same set of fields on one task:

Watch the video walkthrough on YouTube

3. Bound the task agent with stored context

src/lib/convex/todo/agent.ts defines when the agent may generate a motivation letter. It reads the job description, the stored CV or profile, and the user’s reusable letter instructions. It generates only when the task reaches the preparing stage and the letter field is empty, which prevents an agent run from silently overwriting a reviewed draft.

src/lib/convex/userSettings.ts manages the reusable profile and instructions. src/lib/convex/todo/messages.ts runs the model interaction, and the resulting letter is written back to the existing task for review, editing, copying, or download. The model call is one bounded step inside application state, not the state itself.

Watch the video walkthrough on YouTube

4. Match Gmail events to existing tasks

The Gmail integration is implemented in src/lib/convex/gmail.ts. OAuth requests read-only Gmail access. The sync retrieves recent messages, extracts sender, company, position, interview links, and date text, then scores candidate tasks with scoreTaskMatch. Strong company and position evidence increases confidence before an application record is updated.

Heuristics handle clear interview, rejection, acceptance, and follow-up signals first. A model fallback is reserved for messages that remain ambiguous. This ordering controls latency and model use while keeping the final task mutation explicit. Gmail is an input signal; Convex remains the source of application state.

Watch the video walkthrough on YouTube

Engineering decisions behind the workflow

The project keeps interactive state, long-running search, persistence, external email, and model calls behind separate interfaces. It also includes retry-aware actions, stuck-task cleanup, duplicate prevention, and explicit user-visible states. Those details matter more than the number of features because they determine whether the workflow survives partial failure.

To adapt JobPilot, start in My Job Search with your own keywords. For code-level changes, the main extension points are the SvelteKit API routes, Convex schema and actions, the FastAPI search service, and the Supabase search schema.

How to repeat this

The code is in Mbehbahani/JobPilot. You need Bun, Node.js and a Convex project; put CONVEX_DEPLOYMENT and PUBLIC_CONVEX_URL in .env.local. Then one command runs the SvelteKit app and the Convex backend side by side:

git clone https://github.com/Mbehbahani/JobPilot
cd JobPilot
bun install
bun run dev

Read src/lib/convex/schema.ts first: every other part writes into the task record defined there.
Add one job from a URL and check which fields src/lib/convex/todo/jobInput.ts filled in.
Move the task to the preparing stage and confirm the agent writes a letter only when the letter field is empty (src/lib/convex/todo/agent.ts).

Gmail and the personal search service need their own credentials, so start without them. To use the hosted version instead, open JobPilot (sign-in required). The per-user model connection is described in Connecting JobPilot to ChatGPT on the old blog.

Deploying MLflow on Railway

Sun, 01 Mar 2026 00:00:00 GMT

Written in March 2026. The monthly cost is a snapshot from then. Corrected in October 2026: the artifact storage variable was wrong (see What went wrong).

I deployed MLflow because local mlflow ui processes and SQLite files could not provide a stable tracking target for several repositories. The Railway deployment (mlflow-tracking-server) runs the tracking server as a container, stores MLflow metadata in PostgreSQL, and sends artifacts to external object storage.

My JobLab agent (joblab-agent-api) uses this server for production request traces, tool spans, evaluation runs, feedback assessments, and prompt-optimization results. The observed deployment was about $20 to $25 per month. That is a snapshot from my services, not a fixed platform price.

Watch the video walkthrough on YouTube

Deploy and verify the tracking server

1. Create the services

The template creates the MLflow service and its PostgreSQL metadata dependency.

2. Inspect the MLflow container

Confirm the tracking process, database variables, public domain, and restart behavior before connecting an application.

3. Configure clients

MLFLOW_TRACKING_URI=https://your-mlflow-url

The JobLab backend reads this value through its settings layer. Evaluation scripts also call mlflow.set_tracking_uri() explicitly so local runs and production requests resolve to the same server.

4. Verify experiment metadata

Create a test experiment and run, then confirm parameters, metrics, tags, and artifacts survive a service restart.

5. Verify traces

Send one agent request and confirm it creates one root trace with child LLM and tool spans.

6. Inspect span timing

Check tool latency, model latency, retries, and the inputs that produced the response.

Separate metadata from artifacts

The tracking server is stateless enough to restart because PostgreSQL keeps experiment and run metadata. Large files, datasets, and model artifacts belong in object storage. The diagram below shows those responsibilities.

One server, two external stores: artifacts never live on Railway.

Do not keep durable artifacts only on the Railway container filesystem. The Railway template configures external storage with BACKEND_S3=s3://your-bucket plus scoped AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_DEFAULT_REGION. Then test artifact upload and download after restarting the MLflow service.

How JobLab uses the shared server

The agent backend creates request-wide traces in app/routers/ai.py. Tool spans are added in app/services/joblab_tools.py, while app/services/mlflow_lite.py provides a REST fallback and S3-backed spool when the full SDK or tracking server is unavailable.

The evaluation pipeline is kept under MLFLOW_STEPS/: step1_create_experiment.py creates the experiment, step2_register_assets.py registers versioned assets, step3_run_evaluation.py runs the baseline and links backend traces, and step4_optimization.py evaluates prompt candidates. Custom scoring logic lives in evals/mlflow_scorers.py.

The target trace shape is one user question, one root agent trace, and nested model and tool spans. Distributed trace context connects evaluation calls to backend execution so the UI can show the whole path instead of unrelated fragments.

Every repo logs to the same tracking server.

What made this production-useful

Hosting the UI was the easy part. The useful work was persistent metadata, durable artifacts, one-question-one-trace structure, prompt provenance, feedback assessments, distributed context, and a fallback path for tracking outages. Those pieces turned MLflow from a local run viewer into the observability and evaluation layer for the JobLab agent.

How to repeat this

Deploy the MLflow template on Railway. It creates the MLflow service and its PostgreSQL database. In October 2026 it shipped MLflow 3.10.1.
Set BACKEND_S3 and the three AWS variables so artifacts go to your own bucket.
Point every client at the server:

export MLFLOW_TRACKING_URI=https://your-mlflow-url

Log one test run with a small artifact, restart the MLflow service, and check that both are still there.
For tracing and evaluation, compare with app/routers/ai.py and MLFLOW_STEPS/ in joblab-agent-api.

The MLflow documentation covers the server options. For a smaller service on the same platform, see how I deployed FastAPI on Railway.

What went wrong

The first version of this note told you to set MLFLOW_ARTIFACT_ROOT. MLflow does not read a variable with that name, and neither does the Railway template. If you followed it, your artifacts may still be on the container filesystem and will disappear on the next redeploy. Use BACKEND_S3 as above, then repeat the restart test in step 4.

Deploying FastAPI on Railway

Tue, 17 Feb 2026 00:00:00 GMT

Written in February 2026. The monthly cost is a snapshot from then.

This deployment serves an optimization backend, the scheduler from my repair-shop scheduling work, from the public POST /solve endpoint. The API code lives in app/, the repository includes a Dockerfile, and Railway builds that container after each GitHub deployment. A separate frontend sends the model input to the public API URL and renders the solution.

I had already deployed FastAPI on ECS and on Lambda (joblab-agent-api). For this small, continuously available API, Railway reduced the amount of infrastructure I needed to operate while keeping the container boundary explicit.

From local process to public container

The deployment path is short, but every boundary is testable:

Start app.main:app locally with uvicorn app.main:app --reload.
Exercise GET /, GET /docs, and POST /solve.
Push the repository to GitHub.
Let Railway detect the root Dockerfile and build the image.
Generate a public domain and repeat the endpoint tests against it.

The OpenAPI page at /docs is especially useful here because it verifies request validation and the deployed route before the frontend is connected.

Watch the video walkthrough on YouTube

Runtime and cost are deployment settings

Railway can stop an idle service when serverless mode is enabled. That reduces compute usage for a demonstration API, but the first request after sleep can take longer. An always-active service removes that cold-start tradeoff and consumes resources continuously.

My small instance was around $1 per month at the time of measurement. That number is not part of the architecture and is not a forecast. Request volume, memory, CPU time, egress, plan rules, and current Railway pricing determine the real bill.

What I monitor after deployment

A successful build is only the first check. I use Railway’s service view to inspect application logs, CPU, memory, restarts, and resource estimates. I then call /docs and /solve from outside Railway so the test covers the public domain, TLS termination, container process, FastAPI validation, and solver response.

Connect the frontend through configuration

The frontend should not contain a hard-coded production hostname. It reads the solver endpoint from an environment variable:

NEXT_PUBLIC_API_URL=https://your-railway-domain/solve

For local development, the same client can target:

http://127.0.0.1:8000/solve

This keeps frontend builds environment-specific without changing application code. If you adapt the project, update the request schema on both sides and configure FastAPI CORS for the exact frontend origins you deploy.

What this project demonstrates

The useful part of this example is the complete connection between a model, an HTTP contract, a reproducible container, a public runtime, and a separately deployed frontend. Railway removes several infrastructure steps, but the deployment still depends on correct process binding, environment configuration, CORS, endpoint validation, logs, and cost monitoring.

How to repeat this

The backend is BigPictureFastAPI and the client is BigPictureFrontend.

git clone https://github.com/oploy-eu/BigPictureFastAPI
cd BigPictureFastAPI
pip install -r requirements.txt
uvicorn app.main:app --reload

Open http://127.0.0.1:8000/docs and send one request to POST /solve from there.
Push the repository to your own GitHub account and create a Railway service from it. Railway finds the root Dockerfile.
Generate a public domain and repeat step 1 against it.
Set NEXT_PUBLIC_API_URL in the frontend to that domain plus /solve, and add the frontend origin to the FastAPI CORS settings.

The live optimization demo shows the finished result. For the database side of the platform, see PostgreSQL on Railway.

What went wrong

I wrote above that the frontend should not contain a hard-coded hostname. My own frontend breaks that rule. In src/lib/usePostSolve.ts, the client falls back to the old Railway URL when NEXT_PUBLIC_API_URL is not set, and that Railway service no longer exists (it returns 404). The live demo still works because its build sets the variable and now calls a self-hosted endpoint. If you fork the frontend, remove the fallback so a missing variable fails loudly.

Testing an SCND Cost Function Before Optimization

Thu, 01 Jan 2026 00:00:00 GMT

Before I wrote the full supply-chain network optimizer, I implemented the objective as a standalone scenario evaluator. That let me test units, timing, capacity bands, allocation logic, and cost dominance without involving solver behavior.

A solver can minimize a function exactly as written and still produce the wrong business decision. The evaluator made the economic assumptions visible first.

Model the objective as an independent component

I built scnd.oploy.eu as an interactive evaluator for a Netherlands network over 2026 to 2030. A scenario chooses fulfillment-center opening periods and capacity levels. The evaluation layer allocates demand to the nearest open facility, checks capacity and shortfall, and aggregates the cost by half-year period.

The implemented objective has four parts:

total_cost = opening_capex
           + fixed_facility_opex
           + hub_to_facility_transport
           + facility_to_demand_transport

Opening CAPEX is charged once in the selected period. Fixed OPEX repeats while a facility is active and depends on its capacity band. Transport OPEX depends on both network geometry and allocated flow. The user interface exposes these terms separately so one large component cannot hide a modeling error in another.

Scenario A: 107.9 M€

Scenario B: 105.2 M€

Both networks satisfy the same feasibility checks, but Scenario B evaluates 2.7 million euros lower. The opening schedule and selected capacity bands change when CAPEX begins, how many periods incur fixed OPEX, and how far demand travels.

This comparison is a unit test for the decision logic. I expect an earlier opening to increase facility cost and possibly reduce transport cost. If the component table does not move in that direction, I inspect period indexing, distance units, cost multipliers, and facility activation before trusting an optimizer.

Checks I run before solver integration

A facility pays opening CAPEX exactly once.
Fixed OPEX starts in the opening period and continues only while active.
Capacity is compared with flow in the same unit and time period.
Transport costs use the intended distance and load units.
Infeasible shortfall is reported separately from economic cost.
Identical scenarios return identical component totals.
Small changes in timing produce explainable changes in the breakdown.

Once these checks pass, the same evaluator can become the objective for a MILP, genetic algorithm, particle-swarm method, or another search procedure. The optimization method can change without changing the business accounting.

How to repeat this

Open the SCND demo. It runs in the browser; nothing to install.
Build one scenario and write down the four component totals, not only the final number.
Open one facility a period earlier. Fixed OPEX should go up. Transport cost should stay the same or go down.
If a component moves the other way, check period indexing, distance units, cost multipliers and facility activation before you trust any optimizer built on top.

The same habit later caught a cost function that rewards stockouts in my inventory simulation, and the optimizer it misled is in optimizing reorder points with a noisy simulator.

Building the JobLab Analytics Frontend

Mon, 01 Dec 2025 00:00:00 GMT

Written in December 2025. The dashboard has since moved to or.oploy.eu.

JobLab is the frontend layer of a larger data system. A scheduled Python pipeline (joblab-data-pipeline, described in building JobLab on AWS Fargate) writes normalized postings to Supabase Postgres. This Next.js application reads those records, keeps filter state in Zustand, and renders linked analytical views with Apache ECharts and Mantine components.

The deployed instance at or.oploy.eu is tuned to optimization, operations research, supply chain, decision science, and related quantitative roles. The frontend architecture is reusable with another job taxonomy and dataset.

Frontend architecture

The application uses the Next.js App Router. Dashboard pages live under src/app/dashboard/, reusable chart components under src/components/charts/, filter controls under src/components/filters/, and shared state under src/store/. Server routes in src/app/api/ separate trusted backend calls from browser-side Supabase queries.

The main data path is:

Supabase job records -> API and query layer -> Zustand filter state -> ECharts options -> linked dashboard views

A country, function, skill, or time selection therefore changes a shared query context rather than creating unrelated charts.

Linked views over one normalized schema

The interface includes a job table, education distributions, industry analysis, skills and tools, search terms, country, experience level, job function, and time-series views. Heatmaps, treemaps, maps, and timelines all depend on standardized fields produced upstream.

This is why the pipeline and frontend are separate repositories. Scraping and taxonomy changes belong in the data pipeline. Visual aggregation, filtering, interaction, and responsive layout belong here.

Configuration and extension points

The browser needs NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY for approved client-side access. Trusted server routes can use SUPABASE_SERVICE_ROLE_KEY, and LLM_BACKEND_URL connects the optional AI and CV services. NEXT_PUBLIC_SITE_URL supplies the canonical deployment URL.

To reuse the frontend for another market, change the upstream search and taxonomy first, then update the TypeScript types, available filters, labels, and chart groupings. Replacing only the page title would leave the optimization-specific schema assumptions in place.

Why the dashboard links back to records

Aggregates can hide duplicate posts, title variation, and small sample sizes. Each filtered view therefore remains connected to the underlying job results. I can use a chart to find a pattern, then open the postings that produced it and inspect whether the classification is credible.

That drill-down is also a practical quality check for job_function_std, industry, skills, tools, remote status, and location fields.

What this frontend demonstrates

The technical work is the connection between a normalized analytical schema and an interface that stays understandable as filters interact. Next.js provides routing and server boundaries, Supabase provides the data layer, Zustand coordinates client state, and ECharts handles the dense visual relationships. The public site is one deployed instance of that architecture.

How to repeat this

git clone https://github.com/Mbehbahani/joblab-analytics-frontend
cd joblab-analytics-frontend
npm install
cp .env.example .env.local
npm run dev

In .env.local, set NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY to a Supabase project that holds job records in the pipeline’s schema. Keep SUPABASE_SERVICE_ROLE_KEY for server routes only.
Open http://localhost:3000/dashboard, pick one country filter, and check that every chart changes together.
Click into one bar and compare the postings with the aggregate before you trust the chart.

The records come from the JobLab data pipeline. The finished dashboard is at or.oploy.eu.

PostgreSQL on Railway: Simple Setup, Honest Costs

Sat, 01 Nov 2025 00:00:00 GMT

Written in November 2025. Since September 2026 oploy.eu no longer runs on Railway; it moved to a server I run myself. The Railway setup below is how it worked until then, and the costs are snapshots from that time.

The oploy.eu website runs on Django and Wagtail. When I wrote this, its PostgreSQL database was hosted on Railway. The important part is the application connection: Railway supplies one DATABASE_URL, Django parses it in wagtailio/settings/base.py, SSL is required, and persistent connections are kept for 600 seconds.

The screenshots show the service I actually deployed. They are evidence from one small workload, not a generic benchmark or a fixed price quote.

Why this deployment uses Railway

I compared Google Cloud SQL, AWS RDS, Heroku Postgres, Fly.io Postgres, and Railway. For this Wagtail workload, Railway gave me the shortest operational path from a managed PostgreSQL instance to an application connection string. I did not need to provision a VPC, subnet, or database security group.

That was the engineering tradeoff: less network control, but less infrastructure to operate for a small web application.

See the setup in 24 seconds

The short walkthrough shows how little interface work is needed to get a PostgreSQL service running.

Watch the video walkthrough on YouTube

Connect Django with `DATABASE_URL`

Railway provides a DATABASE_URL containing the host, port, database name, user, and password. In this project, wagtailio/settings/base.py passes that value to dj_database_url.config(), sets ssl_require=True, and uses conn_max_age=600 so Django can reuse connections instead of opening a new one for every request.

DATABASES = {
    "default": dj_database_url.config(
        conn_max_age=600,
        ssl_require=True,
    )
}

The credential belongs in the deployment environment. It should never be committed to Git or copied into an article. A different Django project can use the same pattern, then adjust connection lifetime and pooling for its own traffic.

Measure the deployed database

The snapshots below captured about $0.18 of usage so far and a $0.55 end-of-month resource estimate for this small database. These values are only a timestamped observation from my instance. Workload, storage, plan rules, and Railway pricing can all change the result.

The complete bill matters more than the resource estimate. Railway’s Hobby plan has a $5 monthly minimum with $5 of usage included (still true when I checked in October 2026). In the invoice shown later, the amount due was $6.05 including Dutch VAT. Always check the current plan and pricing rather than treating an old screenshot as a quote.

Region placement changed query latency

When the database was farther from the application and its users, latency was noticeable. Moving it to Railway’s Amsterdam region reduced the network distance and made response time more consistent for this European workload.

For another deployment, place the application and database in nearby regions, then measure the real request path. Provider choice cannot compensate for avoidable network distance.

Monitoring and billing are easy to read

The service view puts CPU, memory, network traffic, storage, connections, and logs in one place. The workspace usage view then connects that activity to an estimated cost. It is enough visibility for this project without assembling several dashboards.

The invoice below is the useful reality check. It separates resource lines, the Hobby plan, included usage, and tax, so the total is not confused with the database-only estimate.

How to repeat this

In Railway, create a PostgreSQL service in the region closest to your application.
Expose its DATABASE_URL to the application service as an environment variable. Do not copy it into code.
In Django:

pip install dj-database-url

import dj_database_url

DATABASES = {
    "default": dj_database_url.config(conn_max_age=600, ssl_require=True)
}

Deploy, open one page, and check the Postgres metrics tab for connections and memory.
Wait for the first invoice and compare it with the usage estimate.

What went wrong

Two things surprised me. First, the database started in a region farther from the application and its users, and the latency was noticeable until I moved it to Amsterdam. Second, a database-only estimate of $0.55 said little about the bill: the invoice shown here was $6.05, mostly the plan minimum and VAT.

When I would use this pattern again

This pattern fits a small application that needs managed PostgreSQL, environment-based configuration, SSL, readable metrics, and a short deployment path.

For regulated workloads, strict availability targets, complex private networking, or large database operations, I would compare backup and recovery guarantees, compliance, connection pooling, support, and high availability before choosing a platform.

Optimizing Reorder Points with a Noisy Simulator

Sat, 20 Sep 2025 00:00:00 GMT

Written in September 2025, when I finished the optimizer behind the simulation-optimization demo. Rerun on 8 October 2026 with the same code; the numbers below are from that rerun.

The inventory simulator tells you what one set of reorder points costs. The next question is which reorder points to choose. With five products and a noisy simulator there is no formula, so I put a genetic algorithm (GA) around the simulation. My earlier ANN metamodel paper (code) took the other route: learn a cheap model of the simulation first.

The setup

Five products with fixed parameters. The GA only chooses the reorder point r of each one.

Product	Policy	Customers/period	Lead time (mean)	Range for r
A	(s,S), S = 50, backorders	10	3	0 to 49
B	(r,Q), Q = 15, lost sales	8	2	0 to 69
C	(s,S), S = 40, backorders	6	4	0 to 39
D	(r,Q), Q = 20, lost sales	12	2.5	0 to 59
E	(s,S), S = 30, backorders	5	3.5	0 to 29

For an (r,Q) product the upper bound is the expected lead-time demand plus three standard deviations plus 25 percent.

GA settings are the API defaults: population 40, crossover rate 0.9, mutation rate 0.3 (adaptive), tournament of 2, elitism 2, 15 percent random immigrants per generation. It stops after at least 25 generations once the best cost has not improved for 10 generations (a change below 0.0005), or at the time limit.

The experiment

I ran the GA three times with different seeds. Then I re-measured each best solution with 200 fresh simulation runs, and did the same for the midpoint of every search range as a naive baseline.

Run	Reorder points (A to E)	Cost the GA reported	Cost re-measured (200 runs)
Midpoints	24, 34, 19, 29, 14		399.2
GA, seed 1	27, 6, 21, 11, 23	329.3	366.3
GA, seed 2	27, 11, 28, 3, 19	322.9	360.2
GA, seed 3	33, 13, 16, 14, 24	327.8	376.9

Each GA run stopped on convergence after 27 to 39 generations, 1,052 to 1,512 evaluations and 7 to 9 seconds.

What the numbers say

The GA’s own score is optimistic. It judges each candidate on 3 noisy runs, so the winner is partly the candidate that got lucky draws. Re-measured, every winner was 11 to 15 percent more expensive than reported. The real gain over the naive midpoints is 6 to 10 percent, not the 18 percent the GA’s own numbers suggest.

Different seeds, different answers, similar cost. Product D’s reorder point came out as 11, 3 and 14. The cost surface is flat and noisy, so the GA stops on whichever plateau it finds first.

The cost function pushes lost-sales products toward stockouts. B and D end with low reorder points and fill rates of 36 to 51 percent. The model has no revenue, so losing a sale (cost 5) is cheaper than serving it (about 5.1). I explain this in the simulation note.

What went wrong

The seed does not make a run repeatable. The GA seeds its own random choices, but every fitness evaluation calls the simulator with base_seed=None. Calling the API twice with "seed": 1 gave [41, 3, 29, 7, 17] and [39, 12, 34, 12, 20]. It also means two candidates are never compared on the same demand. The fix is common random numbers: pass the same seeds to every candidate’s replicates. That makes runs repeatable and the comparison fairer.

/simulate ignores its seed field. It is accepted and then dropped.

My “30 seconds” change did nothing. In September 2025 I raised the time limit from 20 to 30 seconds in optimization.py, but the API request model still defaults to 20, so the API never used it. With these defaults it does not matter: every run converged in under 10 seconds.

Reporting the search score as the result. The demo shows the GA’s own best cost. It should re-measure the final candidates with many more runs before showing a number.

How to repeat this

The code is not public yet; the API and the demo are.

# One GA run (about 8 seconds). Expect different reorder points each time; see above.
curl -s -X POST https://api-simopt.oploy.eu/optimize \
  -H "Content-Type: application/json" -d '{"seed": 1}'

# Re-measure a solution with 50 runs (the API's maximum per call).
curl -s -X POST https://api-simopt.oploy.eu/simulate \
  -H "Content-Type: application/json" \
  -d '{"reorder_points": {"Product A": 27, "Product B": 6, "Product C": 21, "Product D": 11, "Product E": 23},
       "replicates": 50, "horizon": 60}'

Run the optimizer a few times and note best_cost and best_solution.
Re-measure each best_solution with four calls to /simulate at 50 replicates and average the objective values.
Compare: the re-measured cost should come out about 10 to 15 percent above best_cost.

The fill rates of backordered products (A, C, E) are wrong until the fix in the simulation note is deployed. The idea of replacing the expensive simulator with a learned model is in my ANN metamodel paper.

Simulating Inventory Policies with SimPy

Thu, 21 Aug 2025 00:00:00 GMT

Written in August 2025, when I built the simulator behind the inventory simulation demo. Rerun on 8 October 2026 with the same code: the tables below are from that rerun, and the bugs in What went wrong were found then.

Fixed reorder rules ignore variability, so they produce both overstock and stockouts at the same time. I wanted a small simulator that shows the cost of a reorder rule under random demand and random lead times, product by product, before trying to optimize anything.

The model

Each product follows exactly one policy: (r,Q), order a fixed quantity Q when the inventory position falls to r, or (s,S), order up to S. Customers arrive as a Poisson process, each one buys a random discrete amount, and every order arrives after an exponential lead time. A product either backorders unmet demand or loses it.

Every review period the loop is the same:

The inventory position is on hand plus outstanding orders. The cost per period is holding plus shortage plus ordering (a setup cost per order and a cost per unit), averaged over the horizon. The engine is SimPy, with NumPy and Python’s random module for the draws (both seeded together), behind a small FastAPI service.

What I ran

Two products from the demo’s defaults, 60 periods each, 50 seeded runs per reorder point:

Product	Policy	Demand	Lead time (mean)	Unmet demand
A	(s,S), S = 50	10 customers/period, 0.5, 1 or 1.5 units each	3 periods	backordered
B	(r,Q), Q = 15	8 customers/period, 1, 2 or 3 units each	2 periods	lost

Both use holding 1, shortage 5, setup 32 and unit cost 3.

Product A

r	Mean cost/period	SD	Min to max	Fill rate
10	96.4	25.6	61.0 to 190.9	0.62
20	87.8	18.3	63.4 to 144.6	0.66
30	79.4	14.4	59.4 to 131.1	0.75
40	79.1	8.5	66.4 to 101.1	0.84

Product B

r	Mean cost/period	SD	Min to max	Fill rate
10	84.0	4.1	72.6 to 93.2	0.37
20	88.0	3.9	77.7 to 96.9	0.60
30	91.7	3.8	80.7 to 99.2	0.73
40	94.9	3.5	83.5 to 102.8	0.78
50	99.2	3.2	89.4 to 109.3	0.84

(Product A’s fill rates are corrected; see What went wrong.)

What the numbers say

One run is not an answer. At r = 10, a single 60-period run of Product A costs anywhere from 61 to 191 per period. Any comparison of reorder points needs many runs, or the same random demand for both options.

Product B gets cheaper the less it sells. Its cost rises with r, and the cheapest rule serves only 37 percent of demand. That is the cost function talking, not inventory theory: there is no revenue in it. Serving one unit costs about 5.1 (unit cost 3, setup 32 / 15, plus holding), while losing it costs 5. An optimizer will happily learn to stop selling. To fix the model, add the lost margin to the shortage cost of lost-sales products, or require a minimum fill rate. I wrote about the same trap in testing a cost function before optimizing.

What went wrong

The fill rate was wrong for backordered products. A backorder stays in negative stock, and in every later period the whole backlog was counted again as new unmet demand. Product A’s fill rate came out as 0.002 at r = 10, and the optimizer’s copy of the engine reported negative fill rates for another product. The cost is fine (a backorder cost per unit per period is a valid choice); only the metric was broken. The fix is one line in the demand step:

self.unmet_demand += min(shortfall, demand)  # count only this period's unmet demand

With it, Product A’s fill rate is 0.62 to 0.84 instead of 0.002 to 0.74.

The API failed when history was off. run() returns the summary on its own when record_history is false, and a {"summary", "history"} pair when it is true, but the API always expects the pair. So POST /simulate with "record_history": false returns HTTP 400. Returning the same shape in both cases fixes it.

How to repeat this

The code is not public yet, but the API behind the demo is, and it gives the same numbers as my local runs (same seed, same result to the last decimal). One run of Product A at r = 20:

curl -s -X POST https://api-siminv.oploy.eu/simulate \
  -H "Content-Type: application/json" \
  -d '{"horizon": 60, "record_history": true, "random_seed": 1,
       "products": [{"name": "Product A", "reorder_point": 20, "reorder_up_to": 50,
         "demand_rate": 10, "demand_sizes": [0.5, 1, 1.5],
         "demand_probs": [0.3333333333, 0.3333333333, 0.3333333334],
         "lead_time_mean": 3}]}'

It returns "average_cost_per_period": 85.54166666666667 for seed 1.

Keep "record_history": true (see above).
Loop random_seed from 0 to 49 and average average_cost_per_period: that is one row of the tables.
Ignore the reported fill rate for backordered products until the fix above is deployed.

Or move the sliders in the demo. The next step, letting a genetic algorithm choose the reorder points, is in optimizing reorder points with a noisy simulator.

Replacing a Slow Simulation with a Neural Network Metamodel

Sat, 10 May 2025 00:00:00 GMT

Written in May 2025. The work is from my Master’s thesis (2018); the article was accepted and published in 2025 after a long editorial process.

Some simulations take two to five minutes per run. That is too slow to call thousands of times inside an optimizer, but not slow enough to justify building a metamodel up front and trusting it blindly. Inventory models are a typical case (I wrote about a SimPy inventory simulation separately). The paper calls these semi-expensive problems, and asks which surrogate to use for them: an artificial neural network (ANN) or Kriging.

The method

The algorithm (ANN-SMB, a semi-metamodel-based method) works in two phases. This is the flow in main_core_ANN.m:

Start: the corners of the search box plus a maximin Latin hypercube, 50 points in total, each simulated.
Phase 1 explores with the real simulation: a particle swarm step adds 10 new simulated points per round, and the ANN is retrained, for at most three rounds or until the ANN passes validation (leave-one-out cross-validation with a studentized prediction error).
Phase 2 exploits: the swarm searches the trained ANN instead of the simulation, and only the final point is simulated again.
The ANN is a feed-forward network with one tan-sigmoid hidden layer (15 neurons in the code) and a linear output. The swarm is the paper’s spatial-hole PSO variant (SH-PSO).

The same framework with Kriging in place of the ANN is the comparison.

Results

On an (s,S) inventory model:

Metric	ANN-SMB	Kriging-SMB
Average objective value	595.28	603.71
Standard deviation	10.61	14.99
Function evaluations	262.5	264

On five analytical test functions, the ANN version was better on Sphere, Griewank, Schaffer F6 and Rosenbrock, and Kriging on Rastrigin, with 5 to 10 percent fewer function evaluations for the ANN.

What this does and does not show

The difference on the inventory model is not statistically significant (p = 0.913): solution quality is equivalent, and the ANN’s advantage is a smaller spread and slightly fewer evaluations. The tests go up to three decision variables, on continuous problems with low noise, and the result is sensitive to the number of hidden neurons (about 6 percent).

That boundary matters. When I later optimized reorder points for five products with a GA, the problem was discrete, five-dimensional and very noisy: exactly the case this paper does not cover.

What went wrong

The README lists the wrong parameters. It says to tune idp, r, m, h and epsilon in main_core_ANN.m; those names do not appear there. The real settings are at the top of the file (see below).

How to repeat this

You need MATLAB 8.4 or later with the Statistics and Machine Learning Toolbox.

% clone https://github.com/Mbehbahani/ANN-SMB-SemiExpSimOpt, then in MATLAB:
cd Main
main_core_ANN

It starts on the Griewank test function, f=@griewank, with bounds -8 to 8 in two dimensions.
For the inventory model, switch to the commented lines f=@operationfun with Lower_Bound=[450,750] and Upper_Bound=[750,1050].
Num_o_Design_points=50 sets the first design, and Num_o_Samples=1 sets the replications per point.
Other test functions (rosenbrock.m, rastr.m, schaffer2.m, funksphere.m) are in the same folder.

The article: An artificial neural network metamodel to solve semi-expensive simulation optimization problems: a comparative study, Journal of Industrial Engineering, 2025.

Visualizing a Bi-Objective Repair-Shop Schedule

Sat, 12 Apr 2025 00:00:00 GMT

First written in April 2025. The work behind it was published in the Decision Analytics Journal in 2026.

This chart is the schedule the web demo returns with its default parameters: six cars, four repair stations and a seven-hour shift, solved for the lowest idle and overtime cost. Each row is a station, each block is one car’s repair at that station, and its position shows the start and finish time. Hatched blocks are paid time with nothing to do, and anything right of the red line is overtime. The chart turns solver output into a sequence that an operator can inspect.

The optimization problem

The model is bi-objective. One objective reduces total flow time so jobs move through the system faster. The other reduces idle-resource and overtime cost. These objectives can conflict: compressing a schedule may improve completion time while creating expensive resource peaks, and a cheaper resource plan may delay jobs.

The constraints enforce feasible operation order, resource assignment, processing duration, and non-overlap. A valid solution must place every required operation on an eligible resource without allowing two operations to use the same capacity at the same time.

From mathematical model to comparable schedules

I implemented exact mixed-integer programming models and a modified NSGA-II search so I could compare solver-based and metaheuristic solutions. The multi-objective output is a set of non-dominated schedules rather than one unexplained answer. A decision maker can compare flow time with idle and overtime cost, then inspect the selected schedule in a chart like the one above.

Validation on real operational data produced about a 42 percent reduction in total flow time and a 47 percent reduction in idle and overtime costs relative to the comparison case reported in the study. Those figures belong to that dataset and experimental design. They are not universal performance claims.

Reuse the technical work

The public repository contains the official research code, including MATLAB, GAMS, OR-Tools, and FastAPI-related implementations. How the FastAPI version is deployed is in deploying FastAPI on Railway. If you adapt it, replace the operation times, eligible resources, precedence rules, capacity assumptions, and objective weights with your own system data. Then validate feasibility and objective units before comparing algorithms.

How to repeat this

The RepairShop-milp repository has three entry points:

Gams/Flow_time.gms and Gams/Idle_Over_time_cost.gms: the MILP, one file per objective (solved with CPLEX).
MATLAB/Optimizer.m: the modified NSGA-II for larger instances.
ORtools/Idle_Overtime.py: the CP-SAT version behind the web demo.

The fastest check needs no install: open the web demo, solve the sample day, and read the Gantt chart the same way as the one above. To compare with the paper, use Instance 1 from its Table 2 (28 cars, 49 repair procedures): the manual schedule had $469 of idle and overtime cost and 6,188 minutes of flow time; NSGA-II reached $267 and 3,925 minutes.

Read the peer-reviewed article. The code behind it is in the RepairShop-milp repository.

Oploy Notes

My old laptop became a Linux server

What actually runs on it

A separate place to run things

Managing it from Windows

Moving services from Railway and AWS

What went wrong, and what I still have to own

How to repeat this

How to turn a spare laptop into a Linux server

1. Prepare the laptop

2. Connect from Windows Terminal

3. Keep the laptop awake

4. Install Docker and run one service

5. Give a service a public address

6. Add Cockpit and the laptop pages

The Battery page

The Display page

7. Configure battery charging separately

8. Move one cloud application at a time

Railway: app and database together

AWS: replace schedules and execution assumptions

9. Keep it recoverable

How to repeat this

What went wrong

Building JobLab on AWS Fargate

My instance uses optimization-specific retrieval rules

One container runs the complete daily build

Inspect each deployable component on GitHub

Build analytical fields from noisy text

Validate aggregates against source records

Match the compute model to the workload

Infrastructure work is larger than the compute bill

Reuse the right level

How to repeat this

Building JobPilot's Technical Architecture

System boundaries and data flow

1. Personal search as a separate service

2. Normalize every job into one task schema

3. Bound the task agent with stored context

4. Match Gmail events to existing tasks

Engineering decisions behind the workflow

How to repeat this

Deploying MLflow on Railway

Deploy and verify the tracking server

1. Create the services

2. Inspect the MLflow container

3. Configure clients

4. Verify experiment metadata

5. Verify traces

6. Inspect span timing

Separate metadata from artifacts

How JobLab uses the shared server

What made this production-useful

How to repeat this

What went wrong

Deploying FastAPI on Railway

From local process to public container

Runtime and cost are deployment settings

What I monitor after deployment

Connect the frontend through configuration

What this project demonstrates

How to repeat this

What went wrong

Testing an SCND Cost Function Before Optimization

Model the objective as an independent component

Checks I run before solver integration

How to repeat this

Building the JobLab Analytics Frontend

Frontend architecture

Linked views over one normalized schema

Configuration and extension points

Why the dashboard links back to records

What this frontend demonstrates

How to repeat this

PostgreSQL on Railway: Simple Setup, Honest Costs

Why this deployment uses Railway

See the setup in 24 seconds

Connect Django with DATABASE_URL

Measure the deployed database

Region placement changed query latency

Connect Django with `DATABASE_URL`