Aleksandrs Daniils JolkinsHome

Infrastructure / Automation

Aleksandrs Daniils Jolkins

Infrastructure & Automation Builder

I turn messy real-world constraints into small, inspectable production systems across web, Android, and self-hosted operations.

Current focusLinkedIn
Abstract workflow atlas connecting rail lines, map points, a ticket shape, interface panels, and code fragments.

Current focus

Building for recovery, clarity, and bounded operations.

These are active directions, not release claims.

Public evidence below covers only what can be shared safely.

  1. 01

    Ticket recovery and administration

    Making scheduled ticket recovery more durable and administration safer, with clear browser-to-phone outcomes.

  2. 02

    Transport processing

    Improving privacy-conscious transport processing and resilient analyzers behind Kontrole & Vilciens.

  3. 03

    Android recovery

    Strengthening recovery and calm idle behavior for supervised phone-backed workflows.

  4. 04

    Operations and publishing

    Keeping self-hosted resource controls bounded and public publishing deliberately sanitized.

Systems directory

Current systems first. Supporting work and experiments follow.

Four production systems lead the story. Supporting workflows, focused tools, and attributed experiments remain available without competing with the work I operate now.

01 / Current

Current systems

Production systems I actively build and operate.
01

Browser-to-phone production system

Ticket Remote

Purpose

A user-facing system that turns approved browser requests into supervised Android actions and returns clear status and results.

Problem

A phone-backed workflow can fail at access, device readiness, execution, or result delivery. The user needs a clear outcome without seeing sensitive device or ticket details.

What shipped

A browser-to-phone path with explicit access, supervised Android execution, health checks, durable scheduling, and clear result reporting.

Public proof

Device identities, access details, control codes, ticket data, and private runtime state remain outside the portfolio.

02

Public transport systems

Kontrole & Vilciens

Purpose

Public-transport products with web and Telegram entry points for Riga maps, service incidents, and live train-network views.

Problem

Transport information is fragmented across stops, routes, incidents, and fast-changing observations. Useful processing must preserve context without retaining unnecessary private inputs.

What shipped

Riga map and incident views, live train-network views, and focused web and Telegram paths with localized public walkthroughs.

Public proof

Public routes demonstrate maps, departures, train movement, and the reporting flow. Private messages and internal analyzer details are not exposed as portfolio evidence.

03

Android runtime

Pixel/Android Orchestration

Purpose

A reusable Kotlin/ADB runtime that supervises Android tasks, coordinates long-running processes, and supports recovery after interruptions.

Problem

Phone-backed production work crosses app state, device state, long-running processes, and interrupted connections. One-off scripts do not provide dependable supervision or honest recovery.

What shipped

A Kotlin/ADB runtime with task supervision, visible health state, and recovery paths. It enables Ticket Remote and other phone-backed workflows.

Public proof

The public pixel-phone repository documents the sanitized runtime boundary. Device identifiers, private endpoints, account state, and operational logs stay private.

04

Production operations

Self-hosted Production Stack

Purpose

A platform for deploying and operating Go services and related components on self-hosted infrastructure.

Problem

A small service portfolio still needs repeatable releases, health checks, resource boundaries, visible failures, and rollback without publishing its sensitive topology.

What shipped

A Linux and Docker operating layer with containerized releases, monitoring, health checks, bounded diagnostics, DNS lifecycle management, and rollback paths.

Public proof

The sanitized public-ops repository shows the structure and operating patterns while omitting hosts, addresses, ports, credentials, dashboards, and private state.

02 / Supporting

Supporting systems

Publishing and access workflows that support the main portfolio.
05

Developer publishing tool

GitHub Manager

Purpose

A guided workflow for turning local project folders into readable, sanitized public repositories and keeping them synchronized.

Problem

Private working directories are rarely safe or understandable enough to publish as they stand. They mix local context, sensitive material, generated clutter, and assumptions that an outside reader cannot recover.

What shipped

A Python package and command-line flow for discovery, review, sanitization, publication, project summaries, and later syncing. The process keeps the choice of what becomes public visible rather than treating release as a one-click dump.

Public proof

The main repository documents setup and verification; thin frontend and backend mirrors support the sanitized split without being presented as separate portfolio projects. Together they demonstrate the publishing boundary while keeping one coherent product story in this directory.

06

Sanitized private case study

Subscription Workflow

Purpose

A private membership workflow with a Mini App front end for access, renewals, and clear user status.

Problem

Membership systems combine access, renewal, payment-adjacent state, and support context. A public portfolio must explain the product shape without exposing customers or business records.

What shipped

A private access and renewal workflow with a Mini App surface and clear user status.

Public proof

This entry stops at architecture and reliability patterns. Business, payment, customer, account, and internal recovery details are omitted, and no private repository link is published.

Tools
  • Go
  • TypeScript
  • Workflow Automation
  • Infrastructure Automation
  • Technical Documentation

03 / Selected

Selected tools

Focused public tools, each built around one narrower problem.
07

Data product

CSV network map

Purpose

A searchable map that turns coordinate-heavy CSV and spreadsheet measurements into a browsable public dataset.

Read the full story
Problem

Rows in a spreadsheet are difficult to compare when location, connection type, and measurement context matter together. Publishing the raw file would also risk carrying irrelevant or private columns into the public view.

What shipped

A dataset hub with generated summaries, search, filters, synchronized map points and list records, plus commands for adding, replacing, validating, and removing datasets while excluding IP-address fields.

Public proof

The live network map exposes the actual linked-record interaction and gives every published dataset a stable, inspectable route. Selecting a point reveals the value of the transformation more clearly than a screenshot or a raw spreadsheet could on its own.

08

Interactive web system

Particle homepage and game

Purpose

A minimal personal homepage whose ambient particle scene opens into a responsive interactive game.

Read the full story
Problem

A real-time visual can feel distinctive while still failing on modest hardware, touch screens, keyboard use, contrast, or reduced-motion preferences. The challenge was to keep the first impression quiet while making the system resilient underneath.

What shipped

An adaptive simulation with pointer, touch, and keyboard input; ambient and game-like modes; Canvas 2D fallback; WebGPU rendering; persistence; haptics; and runtime performance control.

Public proof

The homepage and interactive route are public, and the implementation is exercised across rendering, scheduling, contrast, session, and input behavior. A visitor can compare the restrained ambient surface with the deeper mode instead of taking the technical description on trust.

09

Native macOS utility

Codex Auth Rotator

Purpose

A native macOS utility for inspecting and switching saved Codex authentication contexts.

Read the full story
Problem

When account state lives in similarly named files, manual inspection is slow and switching the wrong context is easy. The active context and available saved options need to be visible before a change is made.

What shipped

A Swift package with a native interface, saved-context scanning, active-context display, deliberate switching, and a Codex command-line fallback.

Public proof

The sanitized public repository describes the account-selection flow and its boundaries without publishing authentication material. That makes the operational idea reviewable while keeping credentials, tokens, and the contents of active account files outside the evidence.

10

Data parser

Latvian court calendar parser

Purpose

A parser that turns fragmented Latvian court-calendar pages into one coherent workbook for searching and analysis.

Read the full story
Problem

Hearings are distributed across monthly indexes, process-specific pages, and an older character encoding. Civil, criminal, and administrative cases expose different details, making a straightforward export inconsistent.

What shipped

A crawler that follows populated process links, decodes windows-1257 pages, normalizes shared and case-specific fields, enriches criminal rows with cited law text and summaries, and writes a single Excel result.

Public proof

The repository exposes the parsing path and output model, making the transformation from court pages to workbook inspectable. The published structure connects each awkward source constraint to a concrete normalization step instead of presenting the spreadsheet as unexplained output.

11

Scheduled automation

task-executor

Purpose

A public scheduling wrapper that triggers maintenance work while private application logic stays behind a deliberate boundary.

Read the full story
Problem

Scheduled jobs need visible timing, repeatable execution, and reviewable wrappers, but the endpoints and business operations they invoke may be sensitive. Mixing both sides makes safe publication harder.

What shipped

A Shell-led repository with GitHub Actions workflows, scripts, and documentation that exposes what is scheduled and how the runner is arranged while leaving application-specific operations private.

Public proof

The repository makes the boundary legible: public orchestration can be inspected without revealing the protected work it activates. That separation also keeps schedule changes reviewable without requiring the private application to become part of the public maintenance surface.

12

Versioned policy

Arbuzas DNS policy

Purpose

A deliberately small repository that publishes a DNS blocklist policy as a clear, reviewable operational rule.

Read the full story
Problem

A policy hidden in an untracked local file is difficult to review, link, or maintain. Rebuilding it as an application would add machinery without making the decision itself clearer.

What shipped

A focused public definition under version control, with enough repository context for an operator or future reader to understand what the blocklist represents and how changes are tracked.

Public proof

The artifact is directly inspectable on GitHub. Its restraint is intentional: the public policy, history, and stable link are the product surface. It is an example of choosing a durable document when an interface or service would obscure the decision.

13

Batch utility

Google Takeout rename script

Purpose

A compact Python utility for correcting duplicate Google Takeout JSON filenames in a directory.

Read the full story
Problem

Takeout-style duplicate markers can land after the wrong extension, leaving large exports inconsistent and tedious to clean by hand. Any batch correction also needs to make overwrite risk visible.

What shipped

A command-line script that separates the base name, duplicate number, and extension, then rebuilds each matching filename in a consistent order across a chosen directory.

Public proof

The public repository includes the runnable utility, before-and-after examples, and the overwrite warning needed to understand its narrow operating boundary. The small scope makes the result easy to verify against representative filenames before applying it to a larger personal archive.

04 / Archive

Archive & experiments

Retired tools, attributed forks, and earlier experiments kept as context rather than current products.
14

Personal automation

gribu.lv Telegram notifier

Purpose

A Telegram-controlled watcher that reports meaningful changes in unread messages instead of demanding constant manual checks.

Read the full story
Problem

A personal inbox can require attention without deserving continuous polling or repeated browser visits. Sessions expire, message counts fluctuate, and a noisy notifier quickly becomes another thing to manage.

What shipped

A Python service with on, off, status, debug, check-now, reauthentication, and help commands; adaptive polling; session-cookie maintenance; retries; health checks; and supervised runtime behavior.

Public proof

The public repository documents the controls, quiet-until-changed notification rule, container path, and secret-aware delivery setup. It also shows how session failure and process health are treated as normal operating states rather than invisible edge cases.

15

Forked systems work

Clawdex Cloudflared fork

Purpose

A practical fork exploring remote mobile and macOS control of Codex through a carefully bounded Cloudflare Tunnel path.

Read the full story
Problem

Remote control is useful, but casually binding a local bridge to the network creates an unacceptable exposure. The host, bridge, mobile client, tunnel, and health state need explicit boundaries.

What shipped

A macOS host, Rust bridge, Expo mobile client, policies, health checks, tunnel setup, and a legacy TypeScript path, with the bridge kept on localhost before controlled publication.

Public proof

The attributed public fork documents the component map and quickstart, so the remote-control experiment can be inspected in the context of its upstream project. Attribution remains part of the evidence, not a footnote, because the work extends an existing system.

16

Archive

Older forks and experiments

Purpose

Two public automation forks kept as an honest record of earlier experiments rather than presented as original products.

Read the full story
Problem

A portfolio can erase older work or overstate it. Forks still show what someone explored, but they need clear attribution and a boundary between historical learning and maintained original releases.

What shipped

An archive entry that identifies the Duolingo and Microsoft E5 auto-renew projects as forks and explains their place in the wider body of work without treating them as maintained original releases.

Public proof

The repositories remain identifiable on GitHub, where their fork relationship can be judged without inflated claims. Keeping this archive in the same story format gives the history equal clarity while preserving a firm distinction between exploration, adaptation, and original product work.

Tools
  • Python
  • GitHub forks
  • Automation research
  • Learning

How I work

Useful before impressive.

The technologies change with the surface. The operating pattern stays deliberately small, direct, and evidence-led.
  1. 01

    Start from real friction

    I begin with the part of a workflow that keeps wasting attention: uncertainty during a train journey, an unread-message check, an opaque file export, or a private access path. That concrete pressure defines the product more reliably than a feature list.

  2. 02

    Ship the smallest useful surface

    The answer may be a localized page, a Telegram command, a searchable map, a native control, a parser, or a versioned policy. I choose the narrowest form that makes the task calmer while keeping private state outside the public product.

  3. 03

    Verify what reaches users

    A local implementation is only part of the result. I check the rendered route, language behavior, phone layout, links, data boundaries, and public repository so the visible proof matches what the product actually does.

Tools chosen to fit the work

  • Next.js
  • TypeScript
  • Python
  • Kotlin
  • Go
  • Swift
  • Telegram
  • Maps and data
  • Automation
  • Browser testing