radu.circei / devops

DevOps L3 Platform Support

L3 platform support at CELUM across AKS, on-prem systems, Azure SQL, APIs, and integrations. Outside work, I run a serious homelab for infrastructure automation, observability, release paths, and recovery.

Download CV Email GitHub LinkedIn

Skills

Platform

  • AKS
  • Kubernetes
  • Docker
  • Linux
  • Azure SQL
  • on-prem systems

Infrastructure

  • Ansible
  • WireGuard
  • Traefik
  • Caddy
  • nginx
  • Cloudflare

Observability

  • Grafana
  • Prometheus
  • centralized logs
  • SQL triage
  • API validation

Delivery

  • GitHub Actions
  • Docker Compose
  • health-gated deploys
  • release manifests
  • SHA256 checks

Code

  • Python
  • JavaScript
  • TypeScript
  • Bash
  • PowerShell

Languages

  • Romanian native
  • English C1-C2
  • German learning

Experience

CELUM (Contractor via Weasweb) – DevOps Support Engineer

dec 2025 – present · remote

L3 support for a Digital Asset Management platform across Azure/AKS and on-prem. I triage platform issues, isolate root cause with logs and metrics, validate SQL/API behavior, and hand engineering clear evidence when code or environment changes are needed. I also contribute to the Atlassian Jira/JSM AI support rollout with Rovo agent work, testing, Confluence documentation, and templates.

Steelcase – Service Desk Analyst L2

feb 2024 – dec 2025 · ~2 yrs · cluj-napoca (hybrid)

Shipped a Teams-based AI chatbot MVP from zero allocation, led security incident response, and drove process automation across the NA support team.

Electronic Arts – BioWare – QA Tester

oct 2022 – sept 2023 · ~1 yr · remote

Quality assurance for Star Wars: The Old Republic; built formal defect triage and reporting discipline on a live MMO.

Projects

Systems I designed, run, and still operate: flagship builds up top, the rest indexed below. Open any one for diagrams, runtime proof, and the reasoning behind the build.

Tresor Ops Platform

flagship
status repo

My personal ops platform: one Ansible control plane for the VPS edge, home node, QA mirror, monitoring, public status, backups, update hosting, bots, and radio workloads.

ansibledockerwireguard
Tresor Ops Platform project screenshot
vot-parlament.ro project screenshot

vot-parlament.ro

status live

A public tracker for Romania's parliamentary votes: official records turned into searchable bills, politicians, parties, source links, and coverage views.

astropostgrestresor index
Tresor Radio Watcher project screenshot

Tresor Radio Watcher

live planes

One cheap RTL-SDR V4 dongle doing two jobs: scheduled Meteor/NOAA weather-satellite captures and a live ADS-B aircraft/weather map over Cluj.

rtl-sdrweather satellitesads-b
Tresor Index project screenshot

Tresor Index

A Tresor-hosted archive layer for signals I do not want as one-off scripts: RSS/news, OLX listings, source health, and Grafana-ready history.

postgresgrafanaansible
BatchYT Downloader project screenshot

BatchYT Downloader

repo

A local media downloader that stopped being a script: GUI and TUI modes, Docker/native profiles, installer builds, and SHA256-verified updates.

pythonpyside6yt-dlp
release/runtime work 1 project
Nursing Pas cu Pas platform project thumbnail

Nursing Pas cu Pas platform

angularnestjsansible

A rough quiz-platform handoff turned into separate frontend, backend, and infra repos with a repeatable QA release path.

repo
website builds 3 projects
Dream Sails migration project thumbnail

Dream Sails migration

astrosanitycloudflare

A client migration still in QA: the useful parts of Dream Sails rebuilt as a faster, easier, and far cheaper website.

QA site
Personal website project thumbnail

Personal website

astrosanityworkers

This site as infrastructure: one static Astro build with DevOps, WebDev, and Photo surfaces, plus Photo Admin driving the photography archive.

repo
Video editor portfolio project thumbnail

Video editor portfolio

astroyoutubecloudflare

A video editor portfolio designed around client-owned content: YouTube playlists act as the lightweight CMS for the work pages.

site
experiments & utilities 4 projects
Service desk AI assistants project thumbnail

Service desk AI assistants

ragjirarovo

Support-AI work in two real service-desk stacks: a tested Steelcase Teams MVP, plus current CELUM Jira/JSM Rovo agent rollout support.

Tresor utility automations project thumbnail

Tresor utility automations

discordpythonsystemd

A family of small always-on services: reminders, source alerts, Minecraft join signals, event watchers, all reporting through Discord.

doomscroll-watcher extension project thumbnail

doomscroll-watcher extension

chrome mv3javascriptcontent scripts

A local browser extension that turns doomscroll routes into an interruption: scroll lock, overlay friction, and host-specific feedback.

repo
Email spam classifier project thumbnail

Email spam classifier

pythonscikit-learnjupyter

A compact ML evaluation project that compares spam classifiers side by side instead of hiding behind one headline score.

repo
// Case study

Case study

Tresor Ops Platform

A homelab that grew into a small operations platform: public edge services, private workloads, monitoring, public status, recovery paths, and service cockpits managed from one documented control model.

ansibledockerwireguardtraefikcloudflare tunnelgrafanaprometheusuptime kumapostgrespythonnginxsystemd
status() repo()

What I built

Tresor started as a homelab and became the operating layer for my own services. It now covers a public Hetzner VPS edge, a private home node, a QA mirror, monitoring, public status, Discord automations, BatchYT update hosting, Tresor Index ingestion, radio workloads, and recovery playbooks.

Operator surface

Tresor Ops Platform tui service inventory.
tui // service inventory

Topology

Tresor Ops Platform topology diagram.
diagram // topology

Control model

The useful part is that it is not a pile of servers I remember by hand. One repo drives the home node, edge VPS, and QA VM. Version pins live in group vars, secrets are split by environment, and the operator view makes service state, public exposure, and failure domains visible before deploy time.

Daily operations

Daily work runs through the Tresor control panel and service-specific cockpits for planes, satellite passes, Grafana, and Tresor Index. They expose lifecycle actions, runtime state, source health, and log context without turning routine fixes into ad hoc shell work.

Service actions

Tresor Ops Platform tui grafana action menu.
tui // grafana actions
Tresor Ops Platform tui infrastructure action menu.
tui // infrastructure actions

Evidence and recovery

Grafana and Prometheus make triage evidence-based, while Uptime Kuma publishes the public status surface. Grafana also reads Tresor Index through a read-only Postgres role, so ingestion health sits next to host and container health. Local backups plus selected R2 replication keep the single-home-host setup recoverable when a service, disk, or config change misbehaves.

Public status

Tresor Status public Uptime Kuma status page showing private and public service uptime.
uptime kuma // public status page

Monitoring proof

Tresor Ops Platform grafana containers dashboard.
grafana // containers dashboard
Tresor Ops Platform grafana host dashboard.
grafana // host dashboard
// Case study

Case study

Tresor Radio Watcher

A radio automation system with two watchers on one SDR: satellites get scheduled LRPT windows, planes get the live map, and the handoff is automated.

rtl-sdrads-breadsbtar1090satdumpskyfieldtlelrptsystemdansibledockerdiscordiss sstv
live planes()

One SDR, two watchers

Built a radio automation system that does two things with one cheap RTL-SDR V4 USB dongle and a small antenna. Satellite Watcher handles scheduled Meteor/NOAA weather-satellite passes. Plane Watcher keeps the same dongle useful the rest of the time with live ADS-B aircraft tracking over Cluj and a weather overlay I use as a quick cloud check.

Plane Watcher

Plane Watcher runs as an Ansible-managed Docker stack on my own Tresor using readsb and tar1090. The public plane map shows aircraft over Cluj and the surrounding region. The weather filter overlay became unexpectedly practical too: whenever I see a plane or a cloud, I open planes.raduhhr.xyz on my phone and check.

Live ADS-B aircraft map over Cluj with weather overlay.
live ui // planes + weather overlay
Plane Watcher terminal cockpit for the ADS-B service.
tui // plane watcher cockpit

Captured weather image

This is a real weather-satellite pass captured from a hill in Cluj-Napoca: Europe, the Black Sea, and North Africa, live from the Russian Meteor M2-4 satellite in polar orbit at 137.9 MHz. Decoded on my own hardware, tracked and notified by my own server.

Meteor M2-4 weather satellite image captured and decoded near Cluj-Napoca.
meteor m2-4 // corrected weather image

Orbit and field constraint

Automatically, the system predicts satellite passes above Cluj-Napoca using orbital mechanics and public TLE data. My balcony acts like a Faraday cage, so for now I go outside with the antenna and laptop for the recording part. The second I have proper line of sight, recording, decoding, and image generation become a config change and redeploy.

Satellite orbit swath map used for weather satellite pass planning.
orbit // predicted satellite swath
RTL-SDR antenna on a tripod outside on a hill near Cluj-Napoca.
field setup // antenna on the hill

Satellite automation

Every day, Satellite Watcher refreshes the TLE cache, picks pass windows, arms the SDR at the right time, records through SatDump, decodes the signal, generates the image, and keeps retention under control. It also supports ISS SSTV events and can be adjusted on demand.

Satellite Watcher terminal cockpit with next pass details and tracked satellites.
tui // satellite watcher overview
Satellite Watcher terminal cockpit showing lower pass and capture controls.
tui // satellite watcher capture controls

Pass notifications

The same watcher posts a Discord digest with future pass schedules, every two nights at 20:00. The useful windows are visible before they happen instead of being discovered afterward in logs.

Discord notification with scheduled weather satellite passes above Cluj-Napoca.
discord // pass schedule digest

Operational shape

Both watchers run off the same single SDR. When a satellite pass is scheduled, ADS-B pauses for the LRPT window and resumes after. No second dongle, no wasted hardware, and less heat from random scanning all day. The whole path is RTL-SDR -> SatDump recording -> corrected imagery -> Discord schedule, backed by orbital predictions, systemd timers, decode profiles, and retention automation.
// Case study

Case study

BatchYT Downloader

A local media-ingest app packaged like something I would actually ship: desktop UI, terminal mode, release artifacts, update manifest, and a locked-down Tresor automation path.

pythonpyside6yt-dlpdockergithub actionsffmpegnodeinno setupnginxansiblesha256
repo()

What I built

BatchYT started as local download tooling and grew into a small packaged product. It normalizes pasted URLs, dedupes jobs, preserves runtime profiles, validates output folders, supports MP3/MP4 modes, and keeps media-library friendly output as a first-class workflow.

Desktop app

BatchYT Downloader gui desktop app.
gui // desktop app

Two operator modes

There are two ways to drive it. The PySide6 GUI runs downloads in a background worker while logs stream into the window. The terminal mode keeps Docker Desktop and native runs useful without pretending a local batch job needs a web app.

Update discipline

The release path is the stronger engineering signal. Version tags trigger a Windows build, PyInstaller bundles the app, Inno Setup creates the installer, `update.json` records version and SHA256, and a restricted deploy user promotes artifacts into the Tresor VPS nginx bucket. The manifest is published last, so installed apps never see an update before the installer exists.

Release path

BatchYT Downloader release and update pipeline diagram.
diagram // release and update path
BatchYT Downloader tui docker profile.
tui // docker profile

Artifact proof

BatchYT Downloader proof installer + manifest.
proof // installer + manifest

Tresor automation

Part of BatchYT also lives on Tresor as a separate scheduled ingest path. An Ansible role deploys a locked-down systemd service and timer, keeps cookies outside git, checks only the newest private playlist entries, writes a playlist-order file, and refreshes the media library after successful runs.
// Case study

Case study

Tresor Index

A shared ingestion layer where disposable collectors write durable Postgres history: sources, fetch runs, item versions, observations, quarantine, and dashboard-ready metrics.

postgresdockeransiblepythongrafanarssolxschedulerdata modelingobservability

What I built

Tresor Index is the archive contract for sources that would otherwise become one-off scripts. Collectors can stay disposable; the durable core is the Postgres schema for sources, fetch runs, items, item versions, observations, quarantine records, and future alert events.

CLI proof

Tresor Index tui tresor-index-cli cockpit.
tui // tresor-index-cli cockpit

Runtime map

Tresor Index runtime and data flow diagram.
diagram // runtime and data flow

Runtime shape

The runtime is intentionally narrow: an app image, a Postgres container, and a scheduler container. The database stays on the internal Docker network, while the scheduler gets egress for source fetching. Source configuration is reconciled from Ansible, so adding RSS feeds is usually a config change rather than an app rebuild.

Operator workflow

Operations are exposed through playbooks and a dedicated `tresor-index-cli` cockpit: deploy, status, source list, one-off source runs, latest listings, and district summaries without touching the database by hand.

Source scope

The current scope covers Romanian news, global tech/security/AI feeds, and OLX real-estate listings across configured cities. Listing observations extract price, area, rooms, district, status, and seller type, so dashboards query stored facts instead of re-scraping pages.

Listing digest

Tresor Index Discord notification with OLX real-estate listing digest.
discord // olx listing digest

Dashboards

Tresor Index grafana news overview.
grafana // news overview
Tresor Index grafana real-estate listings.
grafana // real-estate listings

Feed views

Tresor Index grafana romanian news.
grafana // romanian news
Tresor Index grafana tech news.
grafana // tech news

Read-only observability

Grafana connects through a read-only database role and owns separate news, tech, and real-estate dashboards. Source health and extracted observations are visible without exposing the database publicly.
// Case study

Case study

vot-parlament.ro

A public, verifiable parliamentary vote record built on the Tresor Index data layer, with official-source links and coverage limits made visible.

astropostgrestresor indexpythonschedulercloudflarepublic data
status() live()

Public record

Built vot-parlament.ro to make Romania's parliamentary voting record easier to inspect. You can search final votes from Camera Deputatilor and Senat by bill, parliamentarian, or party, and each available vote keeps a link back to its official source, so the record stays verifiable rather than just summarized.

Public surface

vot-parlament.ro homepage with parliamentary voting overview and navigation.
ui // public homepage

Bill and vote views

vot-parlament.ro bill project page with status, source links, and voting timeline.
ui // bill project
vot-parlament.ro vote detail page with parliamentary vote breakdown.
ui // vote detail

Inspection routes

vot-parlament.ro politician profile with voting history and alignment details.
ui // politician profile
vot-parlament.ro dark mode view.
ui // dark mode

Vote notification

vot-parlament.ro Discord notification with parliamentary vote update.
discord // parliamentary vote update

Coverage

Current coverage runs from February 2016 to the latest indexed session: 7,400+ votes across 7,000+ bills, 1,360 parliamentarians, and 20 parliamentary groups. Dedicated routes for votes, bills, politicians, and parties turn a decade of records into something a citizen can query without digging through official portals.

Data layer

The data layer is Tresor Index. Instead of living as a throwaway scraper, official vote sources are fetched on a schedule, normalized into the Postgres schema, versioned, and kept as durable history rather than pages that must be re-scraped on every visit.

Runtime health

vot-parlament.ro grafana parliament votes.
grafana // parliament votes
vot-parlament.ro grafana API runtime and health.
grafana // api runtime

Delivery

The front end is an Astro SSR app on the same Tresor / Hetzner VPS setup as the rest of my sites, rendering directly from stored vote data. A methodology page documents how votes are matched to sources and what "final vote" means, so the project stays honest about coverage and limits.
// Project

Project

Nursing Pas cu Pas platform

A handoff rescue focused on cleaner ownership, runtime boundaries, and deploy confidence.

angularnestjscaddycloudflare r2cdndocker composepostgresredisansiblegithub actions
repo()

Admin surface

Nursing Pas cu Pas admin interface.
ui capture // admin surface

Handoff cleanup

I split frontend, backend, and infra into separate repos so ownership was clear and deployment logic stopped leaking into application code. That cleanup made the project easier to reason about before feature work continued.

Runtime shape

The release path was rebuilt around repeatability: Angular at the edge, NestJS behind `/api`, Redis for quiz state, Postgres as source of truth, upload/CDN delivery, and GitHub Actions plus Ansible for QA deploys.

Local runtime

Nursing Pas cu Pas platform ui capture local compose runtime.
ui capture // local compose runtime

Runtime snapshot

Nursing Pas cu Pas platform runtime snapshot showing public path, QA edge, app services, and state plus media services.
diagram // runtime snapshot

QA release path

Nursing Pas cu Pas platform QA release path showing frontend, backend, and infra repos plus deploy steps into the QA VPS.
diagram // qa release path

Result

After the platform cleanup, product work became easier to ship. Question management, image-backed quizzes, Romanian copy, and theme fixes all sat on a runtime model that behaved like a maintainable app instead of a rescued folder.
// Website

Website

QA · cutover pending

Dream Sails migration

The new site keeps the offers, enquiries, contact, and newsletter while removing the WordPress weight and cost. Production stays untouched until the remaining hoster, mail, DNS, polish, and handoff work is complete.

wordpress migrationastrosanity cmscloudflare pagespages functionsturnstilemailerlitezoho maildns cutoverstatic delivery
QA site()

Customer problem

Dream Sails mainly needs to present holidays, receive enquiries, and let the owner update content. The old WordPress site made that simple job slow, expensive, and harder to maintain than necessary.

QA surface

Dream Sails QA website preview.
qa // homepage
Dream Sails vacations catalogue with filters.
qa // vacations catalogue
Dream Sails booking request page with native form.
qa // native booking form

What the owner will get

The owner will be able to change offers, copy, images, prices, availability, and testimonials from a focused admin panel. There is no theme or plugin marketplace; a new look, section, or feature becomes a clearly scoped custom change, usually 1–10 hours depending on complexity.

Migration and runtime

Dream Sails migration, content, release, form, and newsletter architecture.
diagram // migration + runtime

Native lead paths

Contact, trip requests, and newsletter signup stay inside the site instead of sending visitors to Google Forms. Enquiries go to the mailbox, subscribers go to their own list, and spam protection runs quietly in the background.

Scope discipline

A separate boat-rental feature reached a working version, but the annual licence cost was too high for the value it brought the client. I removed it from the active site and archived it so it can return if the numbers make sense later.

Measured change

The homepage dropped from roughly 174 KB to 25 KB, while the files that made WordPress feel sluggish dropped from 3.87 MB to 177 KB. At current traffic, hosting can remain free; the expected recurring bill is roughly €10–15 per year for the domain plus about €1 per month for mail.

Still to do before launch

I am waiting for hoster access before touching production. The remaining work covers the WordPress backup, redirects, domain and mail migration, real form delivery, final photography and footer polish, a simpler admin panel, and a safe rollback path.

Owner handoff

The client will receive short illustrated procedures for publishing content, checking mail, reviewing newsletter signups, and knowing when something is a simple content edit versus a custom site change.
// Website

Website

Personal website

A three-surface portfolio running as a static Astro site on tresor-vps: nginx serves the public build, Cloudflare fronts it, Photo Admin manages the photo archive, and contact handling stays isolated in a Worker path.

astrophoto adminsanity cmsworkersturnstileaws sesnginxcloudflare dns
repo()

Three public surfaces

Personal website root page with DevOps, WebDev, and Photo surfaces.
ui capture // root surface

Serving shape

The public site is one static Astro build with three entry points: `/devops` for infrastructure and support work, `/webdev` for client-facing site offers, and `/photo` for the photography archive. Cloudflare fronts the domain, nginx on tresor-vps serves the built files, and client-side JavaScript stays limited to interaction work: themes, modals, lightboxes, navigation state, and form submission.

Current public surfaces

Personal website WebDev surface with client-facing offer and work examples.
ui capture // webdev offer surface
Personal website Photo archive surface with albums.
ui capture // photo archive surface

Photo Admin content path

The photography archive moved from repository-stored album data to a small Sanity-backed admin surface called Photo Admin. Album titles, notes, cover choices, ordered photo lists, alt text, captions, tags, and crop overrides are edited there, while Astro still owns routing, page composition, gallery behavior, CSS, metadata, and the public visual identity.

Publishing loop

Because the site remains statically generated, publishing an album does not mutate the live server directly. A Sanity webhook sends a repository dispatch to GitHub Actions, the existing deploy workflow rebuilds Astro with the latest published Sanity data, and the VPS receives the generated files through the normal deployment path. If Sanity is unavailable during local work, the adapter can fall back to the original repository content.

Runtime path

Personal website runtime path from Cloudflare to nginx on tresor-vps and Astro static routes.
diagram // cloudflare nginx astro routes

Contact path

The contact form deliberately does not post straight to the VPS. A separate Cloudflare Worker handles origin checks, Turnstile verification, KV-backed rate limiting, and SES delivery, so the static site can stay simple while the risky part lives behind a controlled edge function.

Deploy path

Personal website deploy path through GitHub Actions, Astro dist, nginx bootstrap, DNS cutover, and Cloudflare.
diagram // deploy path
// Website

Website

Video editor portfolio

A client-owned video portfolio with focused work categories, playlist-backed updates, and a clean publishing handoff.

astroyoutube playlistscms-like workflowcloudflaremanual buildscontent syncvideo portfolio
site()

Publishing shape

The site was designed as a focused video portfolio from the start: long-form, short-form, and assistant-editor work live on dedicated pages, so visitors can scan the right category instead of landing on one mixed wall of clips.

Owner workflow

The ownership model is simple: he uploads finished work to YouTube, keeps playlist order aligned with how he wants the portfolio presented, and can publish through his own Cloudflare workflow. YouTube is the familiar editing surface, while the static site consumes that ordered content like a small CMS without needing a separate admin panel.

Site overview

Video editor portfolio site overview showing GitHub to Cloudflare Pages deploy path, homepage panel structure, category pages, and contact handoff.
diagram // site overview

Work grid

Video editor portfolio ui capture homepage work grid.
ui capture // homepage work grid

Pages

Video editor portfolio ui capture playlist-backed page.
ui capture // playlist-backed page
Video editor portfolio ui capture contact panel.
ui capture // contact panel

Handoff

The ownership split is intentional: I own the platform shape, frontend, and build path; he owns the content cadence. That matters because the site can keep growing without turning every new edit into a development request.
// Project

Project

tested mvp + ongoing

Service desk AI assistants

Two support-AI contexts with the same practical lesson: the assistant only works when the knowledge, routing, templates, tests, and rollout docs are treated as product work.

ragcopilot studiosharepointteamsjirajsmrovo agentsconfluenceazure ai searchpower automate

Two stacks, same lesson

This is practical support-AI work, not a generic chatbot claim. At Steelcase, the prototype lived in the Microsoft stack and surfaced support knowledge through Teams. At CELUM, the current work lives in the Atlassian stack with Jira/JSM, Rovo agents, templates, testing notes, and Confluence documentation.

Assistant flow

Service desk AI MVP overview showing knowledge path, user and IT agents split, and rollout improvements.
diagram // mvp overview

Steelcase MVP

The Steelcase MVP was a Teams-based support chatbot grounded in existing support knowledge and daily service-desk pain points. I owned the demo flow, test plan, failure analysis, and rollout planning, then tested it with the North America support team.

What testing showed

Testing produced a useful failure map. Most weak answers came from stale, duplicated, or missing KB content rather than the assistant layer itself, so the rollout plan prioritized knowledge quality before broader automation.

Next-step architecture

The next-step architecture was practical: Azure AI Search for stronger indexing, Power Automate for ticket creation, and a sync path once support knowledge content could be published without manual exports.

Current Atlassian work

At CELUM, the same support-AI experience feeds into a Jira/JSM rollout rather than a from-scratch ownership story. I work alongside a senior mentor, built and documented two Rovo agents, help test behavior and templates, and maintain Confluence playbook material from the perspective of someone who has already seen support bots fail or succeed on knowledge quality.
// Project

Project

doomscroll-watcher extension

A Chrome/Brave extension built as active friction for high-attention feeds, with route-aware relocking and local feedback.

browser extensionjavascriptchrome mv3content scriptsux
repo()

Purpose

The extension ships as a Manifest V3 Chromium content script and activates immediately on Instagram, LinkedIn, Facebook, and YouTube Shorts routes. It is built as active friction for Brave or Chrome, not as a passive time tracker.

Overlay proof

doomscroll-watcher extension overlay scroll lock.
overlay // scroll lock
doomscroll-watcher extension overlay scroll lock.
overlay // scroll lock

Behavior

Once active, it does not wait for a time budget. Wheel, touchmove, keyboard scroll keys, and direct scroll events are intercepted, the current position is restored, and newly created feed containers are relocked as the page mutates.

Product choice

The warning layer is part of the product decision: a full overlay stays up for a minute, audio is primed from bundled local assets, and host-specific interruption copy is injected so the block remains consistent even offline.
// Project

Project

Tresor utility automations

Small notification services treated like real operations work: proper users, timers, logs, secrets, and playbooks through Tresor.

discordpythonwebhookssystemdansibledockertresor

Small-service pattern

These services are intentionally small: scheduled checks, source polling, filtering, dedupe, and Discord webhook delivery for workflows that do not deserve a full application surface. They live in Tresor because service users, timers, secrets, logs, and status playbooks still matter when the app itself is tiny.

Notification surface

Tresor utility automations discord notification channels.
discord // notification channels

Reusable shape

The reusable pattern is practical: poll a source, filter for relevant changes, dedupe, and post only when there is something worth seeing. Birthday reminders, Steam-free alerts, RA artist watching, and server join notices all fit that same small-service model.

Alert proof

Tresor utility automations discord steam free games.
discord // steam free games
Tresor utility automations Discord RA Watcher event notification.
discord // ra watcher
Tresor utility automations Discord tech news notification.
discord // tech news

Operational examples

The more operational examples are the useful ones: RA Artist Notifier watches a Resident Advisor artist page for newly listed events, and Paper Join Notifier watches the Minecraft server and posts join signals while a Grafana board tracks server health.

Server signals

Tresor utility automations discord minecraft joins.
discord // minecraft joins
Tresor utility automations grafana minecraft server.
grafana // minecraft server
// Project

Project

Email spam classifier

A classical ML comparison on the UCI Spambase dataset, focused on evaluation discipline instead of a single headline score.

pythonscikit-learnjupyterpandasemail
repo()

Classifier pipeline

Email spam classifier pipeline showing Spambase input, train-test prep, four classifiers, and evaluation outputs.
diagram // classifier pipeline

Saved proof

Email spam classifier saved evaluation plots.
proof // evaluation plots

Evaluation focus

This is a compact classical-ML comparison on the UCI Spambase dataset. The point is not that spam detection is novel; the point is that the notebook keeps model choice honest by comparing Logistic Regression, Decision Tree, Random Forest, and Gradient Boosting side by side.

Pipeline

The pipeline loads Spambase from OpenML, keeps the split stratified, standardizes the numerical feature set, and evaluates each model with accuracy, precision, recall, F1, ROC AUC, confusion matrices, and train-vs-test checks.

Result

The useful part is the comparison layer. Gradient Boosting performs best overall, Random Forest lands close behind, and the saved plots make overfitting and metric tradeoffs visible instead of burying them in one headline number.

Education

Informatics & Economics (FSEGA)

2021 – 2024 · coursework, no diploma

Completed most of the Informatics & Economics coursework before moving full-time into infrastructure and platform work. I did not complete the diploma. The projects above show the practical path since then.

Self-directed infrastructure path

ongoing

Ongoing learning through Kubernetes and Azure support at work; Ansible, Docker, monitoring, reverse proxying, backups, update pipelines, and release automation in my own systems.

Contact

Based in Romania, remote-first, and open to platform, DevOps, and infrastructure work worldwide. I am currently employed, so the best fit is a serious full-time move or a focused infrastructure contract with clear scope.

Timezone
Europe/Bucharest, remote-friendly overlap
Contracting
Romanian PFA available for scoped contract work
Languages
Romanian native, English C1-C2, German currently learning
Focus
platform support, infrastructure automation, release engineering
github/raduhhr linkedin/radu-circei Download CV
0 / 2000

verification

sending...
Open