Radu Circei / Application & DevOps Support

Build.Operate.Explain.

Application / DevOps support engineer with QA, L2, and L3 experience across enterprise platforms, AKS, APIs, and integrations. I build AI support automation, operate my own infrastructure platform, and deliver client websites.

Skills

Application support

  • Incident assessment
  • Runbooks
  • RCA support
  • On-call

Platforms

  • Kubernetes / AKS
  • Docker
  • Linux
  • Azure SQL

Infrastructure

  • Ansible
  • Cloudflare
  • WireGuard
  • Traefik
  • GitHub Actions

Observability

  • Grafana
  • Centralized logs
  • API validation
  • Swagger

AI support

  • Atlassian Rovo
  • Copilot Studio
  • Structured evaluations
  • Playwright

Enterprise tools

  • Jira / JSM
  • Confluence
  • ServiceNow
  • Active Directory
  • Intune

Experience

CELUM (Contractor via We As Web) – DevOps / Application Support Engineer

dec 2025 – present · remote

SLA-driven L3 support for an enterprise Digital Asset Management platform across Azure/AKS and on-premises environments. I investigate production incidents across the application, infrastructure, data, and integrations, then coordinate evidence-backed resolutions with customers, engineering teams, and vendors. I also co-develop support playbooks and AI automation with Atlassian Rovo.

Steelcase – Service Desk Analyst L2

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

L2 service desk support for the North America team. I handled incidents and requests, led security investigations, built two Microsoft Teams AI assistants, and improved support workflows while participating in the on-call rotation.

Electronic Arts – BioWare – QA Tester

oct 2022 – sept 2023 · remote

Tested gameplay and content updates for Star Wars: The Old Republic across regular release cycles, including multiplayer systems and unusual player scenarios. Reported reproducible defects, verified fixes, and automated repetitive test preparation.

Projects

Infrastructure I operate, support workflows I improve, and products I build for people. Open any project for the implementation and evidence behind it.

01

Tresor Ops Platform

flagship

A five-node personal infrastructure platform for public sites, private services, data pipelines, media, and radio, operated through Ansible and a custom control panel.

ansibledockerwireguard
Tresor Ops Platform project screenshot
See more web projects 3 projects

alinrusu.xyz

A video portfolio where new work is organized on YouTube and appears in clear long-form, short-form, and assistant-editor galleries.

Client Website Migration

Ongoing · QA

An ongoing Squarespace replacement for international performances and community projects, with an editable QA site ahead of production migration.

Personal website

A personal product with three distinct experiences: technical projects, client web work, and a photography archive, built and operated on my own stack.

Visit the web development site
More projects 4 projects
Nursing Pas cu Pas platform project thumbnail

Nursing Pas cu Pas platform

angularnestjsansible

Restructured a quiz platform into separate Angular, NestJS, and infrastructure repos with a repeatable QA release path.

repo
doomscroll-watcher extension project thumbnail

doomscroll-watcher extension

chrome mv3javascriptcontent scripts

A Chromium extension that interrupts high-attention feeds with scroll locking, a timed overlay, and site-specific feedback.

repo
Tresor utility automations project thumbnail

Tresor utility automations

discordpythonsystemd

Small Tresor services watch selected sources and events, filter and deduplicate changes, then send useful alerts through Discord.

Email spam classifier project thumbnail

Email spam classifier

pythonscikit-learnjupyter

Compared four spam classifiers on the UCI Spambase dataset using precision, recall, F1, ROC AUC, and confusion matrices.

repo
// Case study

Case study

Tresor Ops Platform

I built and operate the hardware, Linux hosts, public VPS edge, monitoring, and cold-backup path as one documented platform with repeatable service controls.

What I built

Tresor began as a homelab and became the platform behind my public sites and private services. I built its physical network and Linux hosts, then separated administration, compute, QA, backup, and the Hetzner public edge. The same control model now runs deployments, data collection, media services, radio workloads, monitoring, and recovery.

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

Prometheus and Grafana put host, container, and ingestion health in one place; Uptime Kuma publishes service status. A dedicated cold-backup node wakes for scheduled synchronization and powers down afterward. Playbooks and documented restore paths make recovery an operation I can run, not a plan that only exists on paper.

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

Radio Ground Station: Plane Tracking & Earth Imaging

One shared SDR serves a public aircraft map and scheduled satellite reception. Pass prediction, receiver handoff, decoding, and plane-tracking recovery are automated.

One SDR, two watchers

An antenna and RTL-SDR receiver feed two services. Plane Watcher decodes aircraft transmissions into a public map over Cluj, with a weather overlay for context. Satellite Watcher predicts suitable passes, records the radio signal, and turns it into images of Earth. The scheduler hands the shared receiver between them.

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

Pass planning and reception

The scheduler uses public TLE orbital data to predict when a satellite will pass above Cluj-Napoca. Reception still depends on antenna placement and a clear view of the sky, so I test field captures as well as the scheduled path, then compare the decoded image with the predicted pass.

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

Media Pipeline

A self-hosted media pipeline for automatic collection, high-quality downloads, metadata cleanup, deduplication, streaming, and offline mobile playback, with separate desktop and terminal tools.

What I built

The everyday workflow is simple: I like music on YouTube, and the scheduled pipeline brings it into my library in the same order. Jellyfin and Navidrome serve it at home or on the web, while my phone keeps an offline copy. Behind that are playlist synchronization, quality settings, metadata normalization, duplicate detection, backups, and alerts. The separate BatchYT desktop and terminal apps handle on-demand audio and video downloads.

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

Tresor runs the liked-video ingest on a systemd timer. It checks recent private playlist entries, keeps credentials outside Git, preserves playlist order, and refreshes the media servers after successful runs. A separate full inventory moves tracks that remain unliked out of the active library into a recoverable quarantine. The desktop app has its own Windows build and update pipeline.

// Case study

Case study

Tresor Index - Data Platform

Configurable collectors feed a versioned PostgreSQL archive with source health, deduplication, observations, APIs, dashboards, and more than 300,000 stored records.

What I built

Tresor Index turns recurring collection into a durable data product. Instead of running isolated scrapers, I keep source definitions, fetch runs, items, versions, observations, and quarantined records in PostgreSQL. Scheduling, validation, deduplication, and change tracking make the archive useful for both public applications and private analysis.

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

Current collectors cover Romanian news, global technology and security feeds, OLX property listings across configured cities, and official parliamentary records. Property observations retain price, area, rooms, district, status, and seller type; the public civic application and Grafana dashboards read stored facts instead of re-scraping pages for each visit.

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

Civic Transparency Platforms

vot-parlament.ro covers more than 20,000 votes and 4.1 million voting positions; ce face primăria? indexes more than 860,000 local-government records across 1,437 municipalities.

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.

Local government

Built ce face primăria? to make local council decisions, proposed projects, and public purchases searchable across 1,437 Romanian municipalities. The index holds more than 860,000 records, including supplier and contract details where available, and retains links to the original documents.

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

The public index currently holds more than 20,000 recorded votes, 4.1 million nominal voting positions, and 8,800 legislative dossiers dating back to February 2016. Dedicated views for votes, bills, politicians, and groups make the records explorable, while the site marks gaps and distinguishes official source data from its own interpretation.

Data layer

Tresor Index ingests official parliamentary sources into PostgreSQL on a schedule. The site reads this stored history through an API rather than fetching official pages for each visitor, and retains source links so people can check a vote against the original record.

Runtime health

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

Delivery

Both civic sites run independently on Tresor with their own API and database. Parliamentary records update automatically; municipal records are published through validated, versioned releases with a rollback path. The sites retain source links and explain coverage limits so visitors can check the underlying records.

// Project

Project

Nursing Pas cu Pas platform

A platform handoff made maintainable through clear repository ownership, defined runtime boundaries, and automated QA deployment.

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

Live · production

Dream Sails (dreamsails.ro)

Dream Sails is live on its own domain with Sanity-managed vacations, native forms, a private reservation register, preserved SEO and mail, and a documented release and recovery process.

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.

Production site

Dream Sails live homepage.
live // homepage
Dream Sails vacations catalogue with filters.
live // vacations catalogue
Dream Sails booking request page with native form.
live // native booking form

Editable content

Vacation details, pricing, itinerary, map stops, galleries, and testimonials are modelled in Sanity. QA and Production have separate datasets and Studio workspaces, so content can be reviewed before public release.

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. Authenticated SMTP delivers enquiries to the existing mailbox, a protected D1 register tracks vacation requests, and MailerLite owns subscriptions.

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.

Migration continuity

Seven genuine legacy vacation URLs were preserved. Renamed pages received explicit redirects, relevant old images were retained, and the mail DNS was separated from the website cutover so the existing mailboxes and course site stayed available.

Release and recovery

The production source has a guarded publishing workflow, verified operational backups of code, Sanity datasets, and D1 data, and documented restoration steps. The legacy hosting archive was preserved before the domain cutover.

Owner handoff

A project handover documents content ownership, mail, forms, admin access, releases, backups, and recovery. The team has a protected admin hub for the services and reservation register it uses.

// Website

Website

Ongoing · QA

Client Website Migration

The QA platform has media galleries, editable content, enquiry forms, and automated deployments. Design and integrations are still being refined with the client before launch.

Project scope

I developed a replacement for a Squarespace website supporting international performances and community projects. The work includes media galleries, content the client can edit, and enquiry forms.

Current stage

The platform is in QA with automated deployments. I am refining the design from client feedback and completing integrations ahead of the production migration.

// Website

Website

Personal website

One Astro site presents my technical and client work alongside a Sanity-managed photography archive. Cloudflare, nginx, GitHub Actions, and a separate contact Worker support the public experience.

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

alinrusu.xyz

The client updates the site through familiar YouTube playlists rather than a separate CMS; the Astro front end turns that ordered content into focused work pages.

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.

// Case study

Case study

ongoing

AI Support Automation

At Steelcase I built and tested Teams support assistants; at CELUM I co-develop Rovo agents, operational playbooks, knowledge automation, and repeatable tests for enterprise support.

Two stacks, same lesson

The work spans two support environments. At Steelcase, I built Teams assistants around ServiceNow knowledge for employees and IT staff. At CELUM, I work with a senior colleague on Atlassian Rovo agents that help operations teams triage tickets, follow playbooks, and use Confluence knowledge consistently.

Assistant flow

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

Steelcase MVP

I built two Microsoft Teams assistants with Copilot Studio and ServiceNow knowledge, tailored to employees and IT staff. I created a Python tool for repeated question testing, analyzed weak answers, and planned the rollout 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.

Evaluation approach

I turned common support questions into repeatable checks and used a Python test tool to compare assistant answers over time. The failure analysis pointed to missing, stale, or duplicated knowledge, giving the team a concrete improvement list rather than a vague accuracy score.

Atlassian agents and evaluation

At CELUM, I co-develop Rovo agents and the supporting operational playbooks, triage rules, structured JSON outputs, and knowledge-management workflows. Testing combines manual review, Atlassian evaluations, JSON checks, and Playwright automation. We refine the agents in sandbox, deploy reviewed changes, and run regression checks against real ticket patterns while training the support team on the workflows.

// Project

Project

doomscroll-watcher extension

Route-aware content scripts detect feed navigation and restore the interruption when pages change, with assets bundled for offline use.

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

Reminders, event watchers, server signals, and source alerts share an operational pattern: scheduled jobs, managed secrets, logs, and playbooks.

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 reproducible Python notebook that shows where Logistic Regression, Decision Tree, Random Forest, and Gradient Boosting succeed or fail.

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)

coursework through 2024 · no diploma

Studied Informatics & Economics at FSEGA through 2024. I did not complete a diploma.

Certified STACKIT Cloud Engineer Fundamentals

jul 2026

STACKIT University / Schwarz Digits.

Got a platform or project in mind?

Contact me

Based in Romania, working remotely, and happy to talk about platform, DevOps, and infrastructure work anywhere. I am currently employed, but always up for a good conversation about a full-time role or a focused contract.

Timezone
Europe/Bucharest, remote-friendly overlap
Contracting
Romanian PFA available for scoped contract work
Languages
Romanian native, English C1-C2
Focus
platform support, infrastructure automation, release engineering
0 / 2000

verification

sending...
Open