Backend APIs and deployment workflows
I build backend services, background-job workflows and deployment tooling. We define permissions, state, retries and recovery before choosing the smallest architecture that fits your workload.

From APIs and self-hosted deployment to bots and automation. Review the code, architecture and limits, then let's discuss the problem you need to solve.
Open, verifiable work
Backend development, deployment, business websites and AI automation. Public projects show the implementation and its current limits.
I build backend services, background-job workflows and deployment tooling. We define permissions, state, retries and recovery before choosing the smallest architecture that fits your workload.
I set up your application on your own VPS and configure Docker, nginx and TLS. Backups, monitoring and hardening are part of the job.
I build WooCommerce stores and custom WordPress plugins, from performance work and product imports to a warranty lookup portal. All on your own infrastructure.
I build bots around what your project needs, with message and member management, cost control and an admin panel. I also use n8n to connect the tools you already use and automate routine work.
Backend systems, deployment tools and live applications. Read the code, explore the architecture and check the release status.
Coming soon
How it works
Explanatory diagram. No server or API connection.
The control plane receives intent to run an HTTP service or a finite job.
Intent and an outbox record are stored together. Sending work is separate from accepting it.
NATS JetStream carries work to Go workers. Message delivery alone does not prove successful execution.
Workers coordinate execution on Kubernetes. Reconciliation and retries follow durable state.
In development
A self-hosted distributed runtime for HTTP services and finite jobs.
Across distributed services, accepting a request is not the same as completing it. This project keeps that distinction explicit.
In development. Build, deployment and recovery acceptance remain under review; not a production multi-tenant platform.
A FastAPI control plane records execution intents in PostgreSQL, sends work through NATS JetStream and coordinates Go workers on Kubernetes. Public v0.1.0 artifacts are available, but build, deployment and recovery milestones remain under review. Not a production multi-tenant platform.
The technical approachA transactional outbox separates accepting a request from dispatching it. Durable intent and idempotent reconciliation support retries without treating message delivery as proof that a workload succeeded. The dashboard remains a prototype.
How it works
Explanatory diagram. No server or API connection.
The Go control plane builds a Docker image from the repository.
The new version runs and is checked before HTTPS traffic changes destination.
Routing changes after the health gate. The build and routing phases remain separate.
Rollback uses the retained image and configuration rather than rebuilding the old source.
Release candidate
Deploy a GitHub repository to one VPS, with health-gated traffic switching.
A new version should demonstrate health before it receives traffic. The deployment flow separates building, checking and switching.
Release candidate. Fresh-VPS acceptance is pending; designed for trusted operators and repositories.
A Go control plane builds Docker images, starts candidates and checks their health before Caddy switches HTTPS traffic. Rollback reuses a retained image and configuration. v1.0.0-rc.1 is a release candidate pending fresh-VPS acceptance, for trusted operators and repositories—not an untrusted tenant sandbox.
The technical approachDeployment phases are persisted in PostgreSQL before their side effects. Build, health checking and routing are separate steps; rollback does not need a fresh source build.
How it works
Explanatory diagram. No server or API connection.
The bot receives text and supported media, then prepares the input for a text reply.
Low-cost rules handle clear cases. Ambiguous messages can reach a small dispatcher with cached decisions.
Provider health, quota and spending limits affect the available route. Basic offline replies remain when APIs are unavailable.
Model health is recorded durably and kept separate from conversation logic.
A self-hosted Telegram persona bot with multi-provider AI routing.
A conversation should not depend on one AI provider alone. Routing, provider health and spending limits are managed separately.
API availability still matters. Basic offline replies are not a full replacement for an AI model.
Handles text, photos, stickers, video and voice input, with text-only replies. The current system includes a Telegram owner panel, provider failover, persistent model health, usage limits and basic offline replies when APIs are unavailable.
The technical approachRouting starts with low-cost heuristics; ambiguous messages reach a small dispatcher with cached decisions. A shared client supports thirteen API providers, while provider health, quota handling and spending limits are kept separate from the conversation logic.
Prerelease
Read-only Linux diagnostics in a Rust CLI and terminal dashboard.
Released
An Android workspace with a real Python runtime and an authenticated MCP bridge.
Serverless GitHub release notifications and a Telegram project directory.
Discord community management with a Telegram bridge.
A Linux terminal assistant that lives inside a Telegram bot.
Scan any shop's category page, get a CSV that imports cleanly elsewhere.
Self-hosted live chat for WordPress and WooCommerce.
A production storefront I built and operate.
A WordPress warranty and product-registration portal.
Public repositories from my GitHub profile.
A fast-paced native 3D magical survival action game built in modern C++17 with Raylib and real-time procedural audio synthesis.
C++High-performance zero-dependency URL shortener engine with SHA-256 Base64URL hashing and persistent Key-Value store
JavaScriptLightweight, secure LAN-based file sharing, folder synchronization, and messaging system with auto-discovery
PythonTools I use in my projects, with hands-on experience deploying and maintaining them.
Follow my projects and releases, ask questions, or share what you are building. Discord is for conversation and member projects; Telegram is for announcements.
Write a few lines about your project or the problem you want solved. I reply within a day, and if the work isn't in my area, I say so up front.
Typical response time: under 24 hours.
Yes. I work with Linux VPS setup, Docker deployment, nginx, HTTPS, backups and monitoring. The focus is infrastructure you control, as used for Astolfo and kgkala.ir.
Yes. My work covers WooCommerce stores and custom WordPress functionality. Hami Hamrah Mandegar is a warranty portal built around a dedicated WordPress plugin; proc123 handles catalogue extraction and import-ready exports.
Astolfo is available as @astolfoaibot for AI conversation, and @hami294bot provides GitHub repository and contact menus. Both have public source repositories. Astolfo availability depends on the API providers it uses.
Yes. GitHub to Telegram publishes public repository activity using Cloudflare Workers and KV. SafeKeeper combines Discord moderation and member tools with GitHub notifications and a Telegram bridge. Both projects are listed below with public source links.
Fill in only what you know. The brief stays in your browser until you copy it or open your email app.
Your brief will appear here as you type.