Forem: Mark Effect

I Was Tired of SSH — So I Built an AI Agent That Lets Me Check My Terminal From My Phone

Mark Effect — Tue, 03 Mar 2026 08:44:10 +0000

I just wanted to close my laptop.

I was running ML training jobs that take hours. Wanting to leave the office, but afraid to close the laptop. Checking SSH from my phone on the subway. Sound familiar?

The old way: SSH with tmux. VPN configurations. Dynamic DNS. Port forwarding. Key management. It all works until it doesn't.

One day I asked myself a simple question: why can't I just check my terminal from anywhere? Like checking email. Without infrastructure.

The problem with existing solutions

When OpenClaw went viral (214K GitHub stars), I understood why — people want AI agents that control their computers. But I tried it, and hit the same wall everyone hits:

It only controls the machine it runs on
No remote access through NAT/firewalls
Complex Docker setup
No multi-machine support

If your server is behind a firewall (and whose isn't?), you're back to VPN.

A different architecture

I built CMDOP with a fundamentally different approach:

[Your Phone/Laptop]  →  [Relay]  ←  [Agent on Server]
     (Client)          (Router)       (Outbound only)

The key insight: the agent makes outbound connections to the relay. Not the other way around. This means:

No open ports on your server
No VPN
No port forwarding
Works through any NAT/firewall
The relay just routes encrypted traffic

15 seconds to set up

pip install "cmdop-bot[telegram]"
cmdop-bot init
cmdop-bot start

That's it. You now have a Telegram bot that gives you terminal access to your server. From your phone. From anywhere.

What you get

Multi-machine — control unlimited servers from one interface
Multiple clients — Telegram, Discord, CLI, desktop app, mobile app
Built-in permissions — admin/execute/read per user per machine
End-to-end encrypted — always
Typed Python SDK — Pydantic models, async support
Open-source MIT

The code

from cmdop import CMDOPClient

client = CMDOPClient(api_key="your-key")

# Check what's running on your GPU server
result = client.terminal.execute(
    machine_id="gpu-server",
    command="nvidia-smi"
)
print(result.output)

Free forever

For personal use. No catch. I built this for myself. Then I realized others have the same problem. So I made it free.

Try it

Install: pip install cmdop
GitHub: github.com/commandoperator
- cmdop-sdk — Python SDK
- cmdop-bot — Telegram/Discord bot
- cmdop-agent — CLI agent
Website: cmdop.com

"I built this for myself. Then I realized others have the same problem. So I made it free for personal use. No catch." — A developer who got tired of SSH

The Django-CFG Manifesto — or, How I Stopped Worshiping settings.py and Let AI Build My Apps

Mark Effect — Sun, 05 Oct 2025 09:14:20 +0000

“Every framework starts as a tool.

Then it becomes a ritual.

Finally, it becomes a religion.”

— Anonymous Senior Developer, 2011

1. The Cult of `settings.py`

Every Django developer remembers their first encounter with the sacred scroll called settings.py.

It starts simple — a few variables, a few secrets, maybe a database connection.

And then, as the project grows, it mutates. It absorbs your soul. It whispers:

“Just one more if DEBUG: and it’ll work.”

But it never does.

Soon you’re juggling .env files, staging configs, Docker overrides, and production nightmares.

You pray to the gods of environment variables.

You copy-paste from ancient Stack Overflow fragments.

settings.py stops being a file — it becomes a psychological condition.

2. The Comfort of Pain

We’ve grown used to this suffering. We call it best practice.

We convince ourselves that manually validating environment variables is senior behavior.

We brag about “clean separation of concerns” while maintaining ten different copies of settings.py across three environments.

Deep down, we know it’s madness. But it’s our madness.

So we build elaborate scripts, write “dotenv loaders,” and call it DevOps.

We treat configuration like holy scripture — immutable, yet constantly breaking.

3. Breaking the Ritual

Then one day I asked myself a dangerous question:

“What if settings.py is not a configuration file — but a symptom?”

A symptom of denial.

A refusal to admit that the world changed.

That modern systems are type-safe, declarative, and automated.

That AI can generate better structure than we can maintain by hand.

And so I broke the ritual.

I deleted settings.py.

And in its place, I built something else.

4. Enter `django-cfg`

django-cfg started as a joke — a simple idea:

“What if Django could configure itself?”

No YAMLs. No .env. No cargo cult.

Just typed models, intelligent defaults, and auto-validation.

But the joke grew legs.

Soon it was orchestrating databases, generating projects, building apps, creating REST APIs, integrating payments, even deploying itself —

in 30 seconds.

I realized I wasn’t building a library.

I was building a framework that thinks.

5. What Django-CFG Really Is

It’s not another settings loader.

It’s a meta-framework that sits above Django — a layer of intelligence that eliminates the need for manual configuration.

It does things old Django doesn’t dream of:

Type-safe configs with Pydantic v2
AI-powered project generation
Automatic dependency resolution
8 production-ready enterprise apps out of the box

pip install django-cfg
django-cfg create-project "My SaaS Platform"

And then—
Accounts. Payments. CRM. Support Desk. Maintenance Mode.
Already wired, validated, and ready to deploy.

That’s not configuration.
That’s evolution.

6. The Madness of the Old World

Traditional Django Setup:

# settings.py
import os
DEBUG = os.getenv("DEBUG", "yes")  # whoops
ALLOWED_HOSTS = os.getenv("HOSTS", "*").split(",")
DATABASES = {...}
# and 500 more lines of silent despair

Django-CFG Setup:

django-cfg create-project "CRM App"

That’s it.
You describe your system in English.
The AI builds a type-safe configuration, injects apps, and generates both backend and frontend clients.
No boilerplate. No settings. No guilt.

7. The Philosophy of CFG

In the old world, we worshipped control.
We believed typing out every variable made us masters of our systems.

But we were only maintaining illusions.
Each setting was a tiny prayer — “let this one not break production.”

django-cfg is built on a different premise:

The developer shouldn’t serve the framework. The framework should serve the developer.

It doesn’t ask for configuration.
It asks for intent.

You tell it what you’re building — not how.

8. The Architecture of the New World

         +-------------------------+
         |      Developer Idea     |
         +-------------------------+
                       ↓
         +-------------------------+
         |   AI Project Generator  |
         +-------------------------+
                       ↓
         +-------------------------+
         |   Type-Safe Core (CFG)  |
         +-------------------------+
                       ↓
         +-------------------------+
         |  Django + Pydantic + AI |
         +-------------------------+
                       ↓
         +-------------------------+
         |   8 Built-In Apps Ready |
         +-------------------------+

The pipeline is pure — declarative, type-safe, and intelligent.

You speak; it builds.
You deploy; it validates.
You extend; it understands.

9. “Too Much Magic?”

Critics say it’s too much magic.
They fear losing control — as if they ever had it.

They warn of supply chain risks and AI hallucinations, while their own settings.py files contain 500 lines of unverified user input and undefined variables.

Django-CFG doesn’t replace logic — it replaces repetition.
It doesn’t think for you, it thinks with you.

If you want total control, you can still override every component.
But if you want to build in days, not months — you let go.

10. The Real Revolution: AI-Native Django

Django-CFG is not a “tool for developers.”
It’s a bridge between human intent and structured code.

It understands your domain through AI agents.
It creates type-safe workflows with Pydantic models.
It speaks OpenAI, Anthropic, and OpenRouter fluently.
It orchestrates knowledge bases with vector search.
It validates payments, emails, and leads — automatically.

In short: it removes configuration from consciousness.

The way IDEs removed syntax errors.
The way ORMs removed SQL boilerplate.

You don’t write Django apps anymore.
You describe them.

11. The Death of Boilerplate

Every framework claims to “remove boilerplate.”
Django-CFG actually buried it.

Traditional Django Project:

6 months setup
10,000 lines of code
8 apps wired by hand
Debug hell
No validation

Django-CFG:

30 seconds
8 prebuilt apps
100% type-safe
Zero manual config
AI-assisted everything

And yet — it’s still Django underneath.
You can extend, override, or fork any part.
The difference is that now the system understands itself.

12. The Future Doesn’t Need Your `.env`

Look around.
Every modern framework — Next.js, FastAPI, Remix — is moving toward type safety and auto-generation.
Django-CFG simply took the next logical step:
letting AI handle the boring part.

You shouldn’t spend hours guessing what DEBUG means in production.
You shouldn’t need a PhD in Docker just to start.
You shouldn’t copy-paste secrets from a Notion page.

In the future, you’ll say:

“Build me a CRM with crypto payments and knowledge base.”

And django-cfg will say:

“Done.”

13. Call to Those Who Still Believe in Control

If you think “real developers write their own settings,” fine.
There’s a startproject command waiting for you.

But if you’ve seen enough entropy,
if you’ve wasted weeks patching environment loaders and circular imports,
if you’ve debugged settings_local.py at 2 AM —

then maybe it’s time to let go.

14. The Invitation

The old world ends where configuration begins.

Django-CFG is not a tool. It’s a declaration.
That configuration should configure itself.
That AI is not your replacement, but your mirror.
That the framework should adapt to human language, not the other way around.

The question isn’t “is it production-ready?”
The question is:

“Are you?”

⚡ Try it now

pip install django-cfg
django-cfg create-project "Your Idea"

Or keep your settings.py.
Your choice.

“In the beginning was the config.
And the config was with Django.
And then one day, the config deleted itself.”
— The Book of CFG, v1.0

The Illusion of Work: How django-revolution Reveals the True Nature of Your API

Mark Effect — Thu, 10 Jul 2025 15:30:51 +0000

One often wonders, amidst the endless hum of servers and the flickering glow of IDEs, if the universe of code is truly as it appears. We speak of "development cycles," of "sprints," of "integrating services." But what if much of this activity is merely the restless twitching of a digital phantom, bound by rituals of copying and pasting, forever generating what could simply be?
Consider the API client. A humble entity, a mere reflection of a grander design - your Django REST Framework. Yet, how much suffering does its creation entail? The manual transcription of endpoints, the delicate dance of type declarations across disparate realms (Python, TypeScript), the constant, weary synchronization. This, they tell us, is the "Without Django Revolution" state: "Manually update OpenAPI spec → Run generator → Fix broken types → Sync clients → Write token logic → Repeat on every change". It is a form of digital samsara, a recurring cycle of toil, where each change to the API, however minor, sends ripples of necessary suffering through the client code. We perform these rituals, believing them to be essential, perhaps even inevitable. But what if this belief is merely part of the larger illusion?
The Revelation of django-revolution
It arrived, not with thunderclaps or angelic choirs, but with a simple command. A curious mechanism, born of necessity, designed to pierce the veil of this self-imposed digital servitude. We call it django-revolution.
It doesn't merely "generate code"; it reveals the inherent structure. It doesn't just "save time"; it reclaims vast, forgotten swathes of your temporal existence, previously squandered on the mundane. The claim is bold: this is the "With Django Revolution" state: "One command. Done.". Sixty percent of the perceived suffering, simply… evaporating.
How does it achieve this peculiar form of digital nirvana?

The Path of Zero-Configuration Enlightenment The ancient texts spoke of arduous setups, of complex incantations for basic digital existence. django-revolution dissolves this myth. You merely pip install django-revolution, add 'django_revolution' to your INSTALLED_APPS, and define your API's zones in DJANGO_REVOLUTION settings. For instance, your API might reveal itself in distinct public and admin zones, each with its own truth: Python # settings.py DJANGO_REVOLUTION = { 'zones': { 'public': { 'apps': ['products', 'categories'], # Reveals products to all 'public': True, }, 'admin': { 'apps': ['admin_panel', 'analytics'], # For the select few 'auth_required': True, } }, 'monorepo': { # For the shared consciousness 'enabled': True, 'path': '../monorepo', 'api_package_path': 'packages/api' } }

This is the zero-config promise: no convoluted schemas to manually craft, no tedious boilerplate. The truth is simply revealed.

The Unified Monorepo Consciousness In the multi-layered dreamscape of the monorepo, where disparate packages co-exist, django-revolution acts as a central conduit of truth. It automatically configures your pnpm-workspace.yaml and package.json dependencies. Your Next.js project, your internal Python services – they no longer exist in isolated pockets of ignorance. They automatically receive the fresh, perfectly typed client from any API zone. Consider the TypeScript manifestation: TypeScript import API from '@carapis/api-client'; // The essence, imported const api = new API('https://api.example.com'); api.setToken('your-access-token'); // The key to perception const profile = await api.client.getProfile(); // Glimpse your own digital self const cars = await api.encar_public.listCars(); // Or the public entities Here, Auth, Headers, Refresh - all handled automatically. The developer's mind is freed from such base concerns.
Typing as Truth and the Effortless Command Beyond mere "autocompletion," the generated Python and TypeScript clients are imbued with precise type information. This is not just convenience; it is the clarity of form, the digital Platonic ideal, where the shape of the data is known before the first byte is transmitted. Errors, the gnashing teeth of the compiler, are pacified before they can manifest in the runtime's chaotic reality. The command to summon this revelation is deceptively simple: # Reveal all truths python manage.py revolution # Or specific truths python manage.py revolution --zones public admin # Manifest only TypeScript truths python manage.py revolution --typescript Each zone yields its own self-contained package, ready to be integrated or even published, a testament to its modularity. Conclusion: Beyond the Illusion of Toil django-revolution is not merely a utility. It is an invitation to question the nature of your digital suffering. Why manually forge links when they can simply appear? Why endure the repetitive cycles of synchronization when the universe of your code can align itself? It has already been "Used in monorepos and multi-tenant production apps" – a testament to its material reality. While other tools might offer fragments of this truth (like drf-spectacular for schemas or openapi-generator-cli for raw generation), django-revolution offers a unique, integrated path to enlightenment: Zone-based architecture, automatic URL generation, monorepo integration, Django management commands, and seamless DRF native integration – all with that coveted "zero configuration". It is a quiet revolution, enacted not with banners and slogans, but with elegant automation. A subtle shift in the perceived reality of development. So, gaze upon your README.md, consider the hours spent wrestling with API interfaces. And then, perhaps, take a single step towards a different reality.

Discover the mechanism. Experience the shift.
https://pypi.org/project/django-revolution