DEV Community: Juan Denis

Python was built for humans, Mapanare was built for AI

Juan Denis — Mon, 09 Mar 2026 01:40:26 +0000

Every language you use today was designed for humans typing code into terminals. Python, JavaScript, Rust, Go — all of them. The abstractions they offer — functions, classes, threads — were built for a world where a human reads every line.

That world is ending.

AI is writing more code every day. Agents are orchestrating other agents. Data flows through reactive pipelines that no human debugs line by line. Tensors get reshaped, multiplied, and dispatched to GPUs in patterns that matter more to compilers than to people.

And yet we're still writing all of it in languages from the 1990s. Bolting on frameworks. Duct-taping asyncio. Praying the shapes match at runtime.

Mapanare is the first language designed from the other side. AI-native. Agents, signals, streams, and tensors aren't libraries — they're language primitives, checked by the compiler, optimized at compile time.

The Problem With "AI + Legacy Languages"

Here's what happens when AI writes Python:

It generates asyncio boilerplate to run two agents concurrently — and gets the event loop wrong half the time
It produces tensor operations with no shape validation — you find out dimensions don't match at 2 AM in production
It writes reactive patterns using three different libraries because the language has no opinion on reactivity
It burns context window tokens on syntactic sugar that exists purely for human readability

The language was never designed for this workflow. Python was built in 1991 for humans who read left to right, top to bottom. We're asking it to do something fundamentally different now, and it shows.

What "AI-Native" Actually Means

It's not a buzzword. It means the language primitives match how modern AI systems actually work:

Agents are first-class citizens

Not a framework. Not a library. A language construct with dedicated syntax, typed channels, and compiler-checked message passing.

agent Classifier {
    input text: String
    output label: String

    fn handle(text: String) -> String {
        // classification logic
        return "positive"
    }
}

fn main() {
    let cls = spawn Classifier()
    cls.text <- "Mapanare is fast"
    let result = sync cls.label
    print(result)
}

spawn, <-, sync — these are keywords, not method calls. The compiler understands agent lifecycle, channel types, and message flow. An AI generating this code can't accidentally forget to start an event loop or mishandle a coroutine — those concepts don't exist.

Reactive signals without the framework churn

let mut count = signal(0)
let doubled = computed { count * 2 }

count.set(5)
print(doubled)  // 10

batch {
    count.set(10)
    // notifications coalesced until batch ends
}

No React. No RxJS. No state management library of the month. The compiler tracks the dependency graph. When AI generates reactive code in Mapanare, it works — because reactivity is a language feature, not a pattern the AI has to remember.

Stream pipelines with automatic fusion

let result = stream([1, 2, 3, 4, 5])
    |> filter(fn(x) { x > 2 })
    |> map(fn(x) { x * 10 })
    |> fold(0, fn(acc, x) { acc + x })

The |> pipe operator is part of the grammar. Adjacent map and filter operations fuse into a single pass automatically — the compiler does it, not the developer, not the AI. Less code, fewer tokens, same result.

Tensors with compile-time shape checking

let a: Tensor<Float>[3, 3] = identity(3)
let b: Tensor<Float>[3, 4] = zeros(3, 4)
let c = a @ b  // shape [3, 4] — checked at compile time

Shape mismatches are caught before runtime. In Python, you find out when NumPy throws an exception. In Mapanare, the compiler rejects it. This is the difference between "AI-generated code that might work" and "AI-generated code that is correct by construction."

Multi-agent composition via pipes

pipe ClassifyText {
    Tokenizer |> Classifier
}

Declarative. Type-checked. The compiler verifies data flows between agents. This is the kind of code AI should be generating — high-level intent with compiler-enforced correctness.

Dual Compilation: Python Ecosystem + Bare-Metal Speed

Mapanare compiles two ways:

Transpiler — emits readable Python, giving you access to the entire Python ecosystem (NumPy, PyTorch, everything)
LLVM backend — emits native binaries via LLVM IR for production performance

The numbers:

Benchmark	Mapanare (LLVM)	Python	Speedup
Fibonacci (n=35)	0.045s	1.189s	26x
Stream Pipeline (1M items)	0.017s	1.034s	63x
Matrix Multiply (100x100)	0.020s	0.456s	23x

And expressiveness — Mapanare programs are consistently the shortest across every benchmark compared to Python, Go, and Rust:

Benchmark	Mapanare	Python	Go	Rust
Fibonacci	10 lines	12	18	23
Message Passing	18 lines	28	27	32
Stream Pipeline	10 lines	17	18	20
Matrix Multiply	14 lines	21	37	33

Fewer lines means fewer tokens. Fewer tokens means more room in the context window. More room means better AI-generated code. The language design feeds back into AI efficiency.

No OOP. By Design.

No classes. No inheritance. No virtual methods. Structs, enums, and pattern matching instead:

enum Shape {
    Circle(Float),
    Rect(Float, Float),
}

fn area(s: Shape) -> Float {
    match s {
        Circle(r) => 3.14159 * r * r,
        Rect(w, h) => w * h,
    }
}

AI models consistently produce cleaner, more correct code with algebraic data types than with class hierarchies. Less ambiguity in the language means less hallucination in the output.

Built With AI. Not "Vibe Coded."

Yes, Mapanare was built with AI assistance. There's an obvious irony in using AI to build a language for AI. But there's a difference between vibe coding and engineering with AI as a tool.

The compiler has ~60 test files. CI runs on every commit. There's a full language spec, an RFC process for language changes, and a self-hosted compiler being bootstrapped — the compiler is being rewritten in Mapanare itself.

This isn't a weekend project that went viral. It's a staged, deliberate effort: Foundation, Transpiler, Runtime, LLVM, Tensors, Self-Hosting, Ecosystem. Each phase ships working software.

The Compiler Architecture

.mn source → Lexer → Parser → AST → Semantic Analysis → Optimizer → Emit
                                                                      ↓
                                                               Python | LLVM IR
                                                                      ↓
                                                       Interpreter | Native Binary

Lexer: 18 keywords, 29 operators
Parser: LALR with precedence climbing
Semantic: Type checking, scope analysis, builtins registry
Optimizer: Constant folding, dead code elimination, agent inlining, stream fusion (-O0 to -O3)
LLVM: Full IR generation via llvmlite with cross-compilation targets

Try It Now

# Linux / macOS
curl -fsSL https://raw.githubusercontent.com/Mapanare-Research/Mapanare/main/install.sh | bash

# Windows (PowerShell)
irm https://raw.githubusercontent.com/Mapanare-Research/Mapanare/main/install.ps1 | iex

# Or install via pip
pip install mapanare

mapanare run hello.mn          # compile and run
mapanare build hello.mn        # native binary via LLVM
mapanare check hello.mn        # type-check only

VS Code extension included — syntax highlighting, snippets, and LSP (hover, go-to-definition, diagnostics, autocomplete).

What's Next

The roadmap is public and concrete:

Phase	Status
Foundation (lexer, parser, semantic)	Done
Transpiler (Python emit)	Done
Runtime (agents, signals, streams)	Done
LLVM (native compilation)	Done
Tensors (compile-time shapes)	Done
Self-Hosting	In Progress
Ecosystem	Planned

The self-hosted compiler means Mapanare will eventually compile itself — no Python dependency. That's the endgame.

Join

Mapanare is MIT-licensed, open source, and looking for:

AI/ML engineers tired of Python's concurrency model
Compiler hackers who want to work on an LLVM backend or a self-hosted bootstrap
Language designers who want to shape semantics via the RFC process
Anyone building agent systems who's sick of framework churn

Python was the last great language built for humans writing code by hand. The next era needs something different.

GitHub: github.com/Mapanare-Research/Mapanare
Manifesto: Why Mapanare Exists

Mapanare — named after a Venezuelan pit viper. Fast strike, lethal precision, native to the land where the idea was born.

AI Settles the Ultimate Venezuelan vs Colombian Arepa Debate (Kimi K2.5)

Juan Denis — Sun, 22 Feb 2026 10:40:57 +0000

The Arepa Wars: Venezuela vs. Colombia vs. Miami Chaos

Forget JavaScript frameworks. Forget tabs vs. spaces. The most passionate, unresolvable debate I've ever witnessed wasn't in a GitHub thread — it was about corn flatbreads.

Specifically: who invented the arepa?

To simulate this high-stakes culinary diplomatic crisis, I used my own open-source tool, CachiBot. Because if you're going to build a chatbot platform, you might as well use it to start international food fights.

🎥 Watch the Debate on YouTube | 🤖 View the actual CachiBot Chat Log

🥊 The Contestants

Three "people" (simulated by CachiBot agents) walked into this debate:

🇻🇪 The Venezuelan Champion: Armed with emotion, a 47-item ranked filling list, and an abuela who wakes up at 5am to prep the masa.
🇨🇴 The Colombian Defender: Five generations deep, mentally cataloging regional varieties, carrying the gravity of someone delivering a sermon.
🌴 The Miami Local: A food blogger with a ring light, 47K followers, and diplomatic immunity from eating arepas "from Weston to Brickell."

🛎️ Round 1: The Origin Story

The Venezuelan opened with historical receipts: "The word comes from 'erepa' in the Cumanagoto language—meaning CORN! We have 3,000-year-old clay griddles to prove it!" (Score: 9/10. Great use of abuela energy.)

The Colombian was unfazed: "The Muisca people in Colombia were making them too! Corn cultivation here dates back 4,000 years! FOUR THOUSAND!" (Score: 9/10. Powerful counter-receipts.)

The Miami Local chimed in: "Actually, indigenous peoples of this whole region made them. The arepa belongs to the LAND, not modern borders!" (Technically correct. Completely unacceptable to both sides.)

🛎️ Round 2: The Varieties

The Colombian went full encyclopedia mode, dropping varieties like dropping mics: Arepa de choclo (sweet corn), Boyacense (cheesy and huge), Santandereana (with chicharrón), and the legendary Arepa de huevo (fried and egg-stuffed).

The Venezuelan countered with pure philosophy. The arepa isn't just food; it's identity. "My abuela doesn't make 'corn flatbread without borders.' She makes Venezuelan arepas. With enough butter to make a cardiologist weep."

🕊️ The "Peace Treaty" Wildcard

Every great debate needs an agent of chaos.

The Miami Local proposed the "Peace Treaty Arepa"—a Colombian arepa de choclo base, stuffed with a Venezuelan reina pepiada filling. The ultimate diplomatic compromise.

The Venezuelan: Would consider it (if the sign says "Venezuelan Arepas" in bigger font).
The Colombian: Would try it "for research purposes."
The Miami Local: Already filming a TikTok about it.

💡 What Does This Teach Us?

Pride in craft is universal. Whether it's your codebase, your open-source library, or your grandmother's masa recipe, people fight for what they build. That's a feature, not a bug.
Attribution is messy. "Who invented X?" is the wrong question. Origins are shared, cultivated over thousands of years by indigenous communities. This is as true for software as it is for food.
Collaboration doesn't erase identity. Fusion is great, but distinct traditions hold their own value. You don't have to merge everything to celebrate it.
The algorithm always wins. The person with the ring light isn't wrong; they're just optimizing for a different metric.

⚖️ Final Verdict

The arepa was born from the land, shaped by indigenous peoples, and belongs to both Venezuela and Colombia in equally valid, delicious ways.

(Look, I programmed the bot to be diplomatic. But I’m Venezuelan, so if there’s a slight bias in the training data... la arepa es nuestra. 🤫)

Have strong feelings about arepas? Want to check out the tool that built this debate? Drop your thoughts in the comments. This is a safe space. Mostly. 🌽🔥

The Armored AI Agent You Can Actually Trust

Juan Denis — Fri, 06 Feb 2026 11:30:00 +0000

I built an open-source AI agent platform that prioritizes transparency and security over "magic". Think Open Claw, but with armor.

The Problem with "Invisible" AI Agents

We've all been there. You fire up an AI agent, give it a task, and... silence. Minutes pass. Is it working? Is it stuck? Did it just rm -rf something important?

Most AI agent tools today operate like black boxes. They promise autonomy but deliver anxiety. You're supposed to trust that the agent is doing the right thing, even when you have zero visibility into what it's actually doing.

I wanted something different.

Enter CachiBot: Visibility = Security

CachiBot is named after the Venezuelan cachicamo (armadillo) — a creature that's armored, deliberate, and doesn't rush into danger. That's exactly the philosophy behind this project.

Core Philosophy

"If you can't see it, you can't secure it."

Every action CachiBot takes is visible in real-time:

Thinking streams — See the agent's reasoning as it happens
Tool calls with arguments — Know exactly what's being executed
Risk analysis — Dangerous code is flagged BEFORE execution
Approval workflows — You decide what runs, not the AI

What Makes CachiBot Different?

1. Sandboxed Code Execution with Risk Analysis

CachiBot uses AST-based static analysis to detect dangerous operations before they run:

# This triggers a HIGH risk warning:
import subprocess
subprocess.run(["rm", "-rf", "/"])

# Risk Analysis:
# - CRITICAL: subprocess import detected
# - HIGH: Potentially destructive command
# - Action: Requires user approval

The sandbox only allows safe imports (json, math, datetime, etc.) and blocks anything that could compromise your system.

2. Real-Time WebSocket Streaming

No more guessing. Watch everything happen live:

[THINKING] Analyzing the file structure...
[TOOL_START] file_list(path="/workspace")
[TOOL_END] Found 12 files
[THINKING] I should read the config file first...
[APPROVAL_NEEDED] python_execute: Risk level HIGH
   └─ Code: os.environ['API_KEY']
   └─ Reason: Accessing environment variables
[USER] ✓ Approved
[TOOL_END] Result: sk-xxx...

3. Multi-Bot Management

Create specialized bots for different tasks:

Bot	Purpose	Model
CodeReviewer	PR reviews	Claude Sonnet 4
DataAnalyst	CSV/SQL work	GPT-4o
LocalHelper	Quick tasks	Ollama (llama3.1)
Researcher	Web searches	Kimi K2.5

Each bot has its own:

System prompt and personality
Enabled tools and capabilities
Knowledge base (RAG with vector search)
Platform connections (Telegram, Discord)

4. Built-in Work Management

CachiBot isn't just a chat interface — it's a work orchestration system:

Work Item: "Refactor authentication module"
├── Task 1: Analyze current auth flow [COMPLETED]
├── Task 2: Design new token system [IN_PROGRESS]
├── Task 3: Implement refresh tokens [BLOCKED by Task 2]
├── Task 4: Write unit tests [PENDING]
└── Task 5: Update documentation [PENDING]

Schedule jobs with cron expressions, set up event triggers, and track everything.

5. Platform Connections

Connect your bots to the real world:

[Telegram] @MyAssistantBot
├── Status: Connected
├── Messages: 1,247
└── Last active: 2 minutes ago

[Discord] CachiBot#1234
├── Status: Connected
├── Servers: 3
└── Last active: Just now

Messages route automatically to the right bot based on your configuration.

The Tech Stack

Backend (Python 3.10+)

FastAPI + async everywhere
Prompture (my structured LLM library)
SQLite with sqlite-vec for embeddings
Sandboxed Python execution

Frontend (React 19 + TypeScript)

Vite 6 for lightning-fast builds
Zustand for state management
Tailwind CSS for styling
WebSocket for real-time updates

LLM Providers

Anthropic (Claude)
OpenAI (GPT-4o)
Moonshot (Kimi K2.5)
Ollama (local models)
Groq (fast inference)

Quick Start

# Install
pip install cachibot

# Start the server
cachibot-server

# Or use the CLI directly
cachibot "Analyze this Python file for security issues"

# Interactive mode
cachibot -i

Then open http://localhost:6392 for the full dashboard experience.

The Approval System in Action

Here's what happens when CachiBot tries to do something risky:

┌────────────────────────────────────────────────────────────┐
│  APPROVAL REQUIRED                                         │
├────────────────────────────────────────────────────────────┤
│  Tool: python_execute                                      │
│  Risk Level: HIGH                                          │
│                                                            │
│  Code:                                                     │
│  ┌──────────────────────────────────────────────────────┐  │
│  │ import requests                                      │  │
│  │ response = requests.get(url)                         │  │
│  │ with open('data.json', 'w') as f:                    │  │
│  │     f.write(response.text)                           │  │
│  └──────────────────────────────────────────────────────┘  │
│                                                            │
│  Risks Detected:                                           │
│  • Network request (requests.get)                          │
│  • File write operation                                    │
│                                                            │
│  [APPROVE]  [DENY]  [APPROVE ALL FOR THIS SESSION]         │
└────────────────────────────────────────────────────────────┘

You stay in control. Always.

Why Not Just Use Open Claw / Open WebUI / etc.?

Great projects! But they solve different problems.

Feature	Open Claw	CachiBot
Focus	Chat interface	Agent execution
Code execution	Basic	Sandboxed + Risk analysis
Approval system	No	Yes
Multi-bot	Limited	Full support
Work management	No	Built-in
Real-time streaming	Partial	Full WebSocket

CachiBot is for when you need an AI that does things — safely.

What's Next?

[ ] MCP (Model Context Protocol) support
[ ] More platform adapters (Slack, WhatsApp)
[ ] Plugin marketplace
[ ] Team collaboration features
[ ] Self-hosted cloud option

Try It Out

pip install cachibot
cachibot-server

GitHub: github.com/jhd3197/CachiBot
Website: cachibot.com

Star the repo if you believe AI agents should be transparent!

I Built My Own DeepSite Alternative That Works with Kimi K2.5, Gemini, or Any Model

Juan Denis — Mon, 02 Feb 2026 04:09:47 +0000

So I got tired of DeepSite.

Don't get me wrong, it's a fun tool. Type a prompt, get a website. But every time I used it I kept running into the same problems. You can't pick the model. You can't self-host it. And there's no quality check on what it generates. You just get whatever comes out and deal with it.

I wanted something where I could plug in whatever model I felt like using that day. Kimi K2.5 just dropped? Let me try it. Gemini got an update? Switch it. Claude writing better code this week? Cool, use that instead.

So I built AgentSite. Open source, self-hosted, and instead of one model doing everything, it uses four AI agents working together like an actual team.

Let me show you what I mean. I just built a travel agency website using Kimi K2.5 and the whole thing took one prompt.

Four Agents, Not One

Here's what happens when you hit generate. Instead of one model trying to plan, design, code, and review all at once, AgentSite splits the work:

Your prompt → PM → Designer → Developer ↔ Reviewer → Done

The PM plans the structure. The Designer builds a color palette and typography system. The Developer writes the actual code. And the Reviewer scores everything and sends it back if it's not good enough.

That last part is the thing I haven't seen anywhere else. The Reviewer agent actually checks accessibility, code quality, and visual consistency. If the score is below 7 out of 10, the Developer gets feedback and fixes it. Up to two rounds of revision. Like an actual code review, but automatic.

Getting It Running

The fastest way is straight from GitHub. There's a Deploy on Railway button right in the README. Click it and Railway handles everything. No terminal, no installing stuff locally.

You can also do pip install agentsite and run it locally if you prefer. But for this demo I deployed to Railway and had a live URL running in a couple minutes.

Setting It Up

Once the app is running you need two things: an API key and a model.

Go to the providers page in settings and paste your key. I added my Moonshot AI key since I wanted to use Kimi K2.5. But you could paste an OpenAI key, Google key, Anthropic key, whatever. You can even add multiple providers and mix them across projects.

Then go to the agents page and set your default model. I set all four agents to moonshot/kimi-k2.5. You could also set different models per agent if you want to get creative, like Kimi for coding and Claude for reviewing.

This is the part DeepSite can't do. New model drops tomorrow? Come back, change the dropdown, done.

Building Ukelele Travels

Alright, the fun part. I created a project called Ukelele Travels, a travel agency that sends people to Venezuela.

Inside the project you get the detail page where you manage all your pages, see the brand identity, and get an overview of what's been generated.

I created a home page, typed my prompt, and let the four agents do their thing. Here's the page builder after generation — chat on the left, live preview on the right.

All of this from one prompt. Kimi K2.5 running through four agents. The PM planned the structure, the Designer picked colors and typography, the Developer wrote the code, and the Reviewer checked it and sent feedback until it passed. No templates, no frameworks, just clean HTML, CSS, and JS.

Tracking Everything

One thing I added that I find really useful is the analytics page. You can see exactly how many tokens each agent used, the cost breakdown, and what happened during each generation.

When you're paying for API calls it's nice to know where the tokens are going. The Reviewer agent barely uses anything compared to the Developer, which makes sense since it's reading and scoring rather than writing full pages of code.

Why I Think This Approach is Better

When you ask one model to do everything, you get a compromise. The planning is okay. The design is generic. The code works but it's messy. And nobody checks it.

When you split the work across specialized agents, each one only has to be good at its job. The PM doesn't need to write CSS. The Developer doesn't pick colors. The Reviewer just reviews. And because each agent gets the output from the previous one as context, everything stays consistent.

I've been running different models through this pipeline for a while now and the multi-agent output is consistently better than any single-prompt approach I've tried. Not a little better, noticeably better.

About Kimi K2.5

Since I used it for this whole demo, some quick notes. Kimi K2.5 is one of the most consistent models I've run through AgentSite. Most models have at least one role where they struggle. Great at coding but the design system is bland. Good at planning but the code output is sloppy.

Kimi K2.5 was solid across all four agents. It's also fast, which matters when you're running four sequential agents plus revision loops. And it never broke the structured JSON schema that the agents use to pass data between each other. Some models hallucinate extra keys or mess up the nesting. Kimi didn't.

That said, the whole point of AgentSite is that you're not married to any model. I built Ukelele Travels with Kimi K2.5 today. Tomorrow I might use Gemini or Claude for the next project. Just change the dropdown.

Try It Yourself

GitHub: github.com/jhd3197/AgentSite

One-click deploy buttons for Railway, Render, and Heroku right in the README. Or pip install agentsite if you want it local.

It's MIT licensed and free. You just bring your own API keys.

If you try it out let me know what model you used and what you built. I'm genuinely curious to see what people come up with.

Why I Built an Open Source SEO Plugin in 2026

Juan Denis — Sat, 24 Jan 2026 02:37:00 +0000

For years, I watched the WordPress SEO landscape become increasingly dominated by proprietary solutions. Yoast, RankMath, All in One SEO—all powerful tools, but all operating as black boxes. You put your content in, and magic happens. Or does it?

The Problem I Kept Running Into

As a developer building WordPress sites for clients, I found myself constantly asking: What exactly is this plugin doing to my markup? Every time I inspected the source, I saw meta tags and structured data that I didn't fully understand or control.

When bugs appeared—duplicate canonical URLs, malformed JSON-LD, conflicting Open Graph tags—debugging was a nightmare. The code was obfuscated. The documentation was marketing-speak. And the "premium" support was often just someone telling me to clear my cache.

The Moment I Decided to Build Something Different

It was December 2025. I was debugging a client's site that had dropped 40% in organic traffic after a plugin update. After three days of reverse-engineering what the SEO plugin was doing, I realized something:

The SEO industry doesn't benefit from secrecy. It benefits from transparency.

Google's algorithms aren't secret anymore. The best practices are well-documented. Schema.org is an open standard. So why are our SEO tools still black boxes?

Introducing Saman SEO

That frustration became Saman SEO—a comprehensive, transparent SEO solution built for developers who believe SEO tooling should be open source, not a black box.

What Makes It Different

Complete Transparency: Every line of code is open for inspection. You can see exactly how your meta tags are generated, how structured data is built, and how redirects are processed.
Developer-First Architecture: Built with hooks and filters throughout. Want to modify how titles are generated? There's a filter for that. Need to inject custom schema? There's a hook for that.
Modern Stack: React-powered admin interface, WP-CLI support, and a clean REST API.

What's Inside

Saman SEO isn't a stripped-down alternative. It's a full-featured SEO toolkit:

Per-Post SEO Fields: Complete meta control with Gutenberg sidebar and classic editor support
Server-Rendered Output: Titles, meta descriptions, canonical URLs, robots directives, Open Graph, Twitter Cards, and JSON-LD
AI-Powered Suggestions: Optional OpenAI integration for intelligent meta generation
Internal Linking Engine: Automated keyword-to-link conversion
Advanced Sitemap Manager: Full XML sitemap control with RSS and Google News support
Redirect Manager: Database-backed 301 redirects with WP-CLI support
Audit Dashboard: Visual issue tracking and automatic fallback generation

This is Just the Beginning

In the coming articles, I'll dive deep into how Saman SEO works under the hood. We'll explore:

The architecture decisions that make it extensible
How to use it for local businesses
Advanced internal linking strategies
Migrating from other SEO plugins
How to contribute to the project

If you've ever been frustrated by black-box SEO tools, I think you'll find Saman SEO refreshing.

The code is open. The standards are shared. Let's build better SEO together.

Resources:

I Built a Free Alternative to cPanel - Here's What I Learned

Juan Denis — Tue, 20 Jan 2026 05:06:55 +0000

The Problem

Last year I was managing a handful of WordPress sites and a few Python apps for clients. My options were:

cPanel - $45/month per server. For 3 servers, that's $1,620/year just for a control panel.
Coolify - Great for Docker but felt like overkill for WordPress sites. I don't need Kubernetes.
CloudPanel - Nice and lightweight but no Docker support. I need both.
HestiaCP - Free and feature-rich but the UI looks like it's from 2008.

I wanted something in between: the simplicity of traditional hosting panels with the power of modern deployment tools.

So I built ServerKit.

What is ServerKit?

ServerKit is an open-source server management panel that lets you:

Deploy WordPress, Flask, Django, and Node.js apps
Manage Docker containers alongside traditional apps
Automatic HTTPS via Let's Encrypt
Real-time monitoring with alerts to Discord/Slack/Telegram
Visual firewall and cron job management
2FA security with ClamAV malware scanning

The Tech Stack

Backend:

Python 3.11 with Flask
SQLAlchemy ORM
Flask-SocketIO for real-time updates
Gunicorn for production

Frontend:

React 18 with Vite
WebSocket connection for live metrics
LESS for styling

Infrastructure:

Nginx reverse proxy
Let's Encrypt via Certbot
Docker & Docker Compose
MySQL/PostgreSQL support

Architecture Decisions

Why Flask over FastAPI?

FastAPI is great for pure APIs, but ServerKit needs:

WebSocket support (Flask-SocketIO is mature)
Template rendering for some pages
Simpler debugging during development

Real-Time Metrics

Every second, the backend collects:

metrics = {
    'cpu': psutil.cpu_percent(),
    'memory': psutil.virtual_memory().percent,
    'disk': psutil.disk_usage('/').percent,
    'network': get_network_stats()
}
socketio.emit('metrics', metrics, broadcast=True)

The React frontend subscribes and updates the dashboard live. No polling, no page refreshes.

Dynamic Nginx Configuration

Each app type has a Jinja2 template:

# PHP app nginx config
server {
    listen 80;
    server_name {{ app.domain }};
    root {{ app.path }}/public;

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php{{ app.php_version }}-fpm.sock;
        # ...
    }
}

When you create an app, ServerKit generates the config, symlinks it, and reloads Nginx.

What I Learned

1. Start with the UI

I built the backend first and regretted it. Users don't see your clean API - they see the interface. Start with mockups, validate the UX, then build the backend to support it.

2. Security is Non-Negotiable

Server management panels are high-value targets. From day one:

JWT with short expiration
TOTP 2FA with backup codes
All secrets encrypted at rest
No shell commands built from user input

3. Real-Time Feels Premium

Static dashboards feel dead. Adding WebSocket-based live metrics made the app feel 10x more polished with relatively little code.

4. Don't Reinvent Everything

I use:

Certbot for SSL (don't roll your own ACME)
ClamAV for malware (don't write an antivirus)
systemd for service management (it works)

Focus on the glue, not the components.

Try It

One-line install:

curl -fsSL https://raw.githubusercontent.com/jhd3197/ServerKit/main/install.sh | bash

Or with Docker:

git clone https://github.com/jhd3197/ServerKit.git
cd ServerKit
docker compose up -d

GitHub: github.com/jhd3197/ServerKit

MIT licensed, no telemetry, no cloud dependency.

What features would make this useful for you? Drop a comment - I read everything.