How I Coordinate Scripts Across Devices Without Open Ports, Firebase, or a VPS

#python #termux #flask #showdev

My scrapers run on PythonAnywhere. My phone runs Termux. I wanted them to talk to each other.

The standard options all had the same problem: they required infrastructure I didn't want to maintain.

Firebase — cloud lock-in, SDK overhead, costs money at scale
Ngrok — exposes a port on my phone, dies when the tunnel resets
A VPS with Redis — another server to maintain, SSH into, keep alive
Webhook to phone — my phone is behind NAT, no open ports

The fundamental issue: cloud scripts push, but phones can't receive pushes without an exposed port or a cloud intermediary.

So I flipped the model. Instead of the cloud pushing to the phone, the phone pulls from a neutral server. Workers poll outbound. No open ports needed. Works behind any firewall.

That's Intent Bus.

How It Works

A lightweight Flask server sits between your scripts and your workers. Scripts post jobs ("intents") to it. Workers anywhere poll for jobs matching their goal, claim them atomically, execute them, and report back.

┌─────────────────────┐
│  Cloud Script                     │ (PythonAnywhere, VPS, Lambda)
│  POST /intent                     │
└──────────┬──────────┘
                  │
                  ▼
┌─────────────────────┐
│  Intent Bus                       │  (Flask + SQLite — free tier works)
│  /intent                          │
│  /claim                           │
│  /fulfill                         │
└──────────┬──────────┘
                  │
        ┌─────┴──────┐
        ▼                    ▼
┌─────────┐  ┌─────────┐
│ Termux        │  │ Linux         │
│ Worker        │  │ Worker        │
│ (phone)       │  │ (Pi, PC).     │
└─────────┘  └─────────┘

The phone worker polls every 10 seconds. When there's a job, it claims it, runs it, and marks it fulfilled. If the worker crashes mid-job, the 60-second visibility timeout auto-requeues it.

Setup in 3 Steps

Step 1 — Deploy the server (free)

Fork the repo and deploy flask_app.py to PythonAnywhere. Set one environment variable:

os.environ["BUS_SECRET"] = "your_secret_key"

That's it. The server is live.

Step 2 — Start a worker on your phone

In Termux:

echo "your_api_key" > ~/.apikey
pkg install jq curl termux-api
bash worker.sh

The worker boots up and starts polling for send_notification intents.

Step 3 — Trigger it from anywhere

curl -X POST https://your-bus.pythonanywhere.com/intent \
  -H "X-API-Key: your_key" \
  -H "Content-Type: application/json" \
  -d '{"goal":"send_notification","payload":{"message":"Scrape complete"}}'

Your phone buzzes.

Real Use Cases

Because workers are just scripts, any device that can run bash or Python can be a worker:

Phone notifications from cloud scripts

# worker.sh on Termux
termux-notification --title "Alert" --content "$MESSAGE"

Log events from multiple machines to one file

# logger.sh on any Linux box
echo "$(date): $TEXT" >> bus.log

Relay alerts to Discord

# discord_worker.sh
curl -X POST "$DISCORD_WEBHOOK" \
  -H "Content-Type: application/json" \
  -d "{\"content\": \"$MESSAGE\"}"

Trigger a deploy on a home Raspberry Pi behind a firewall

# python_worker.py on Pi
if goal == "deploy":
    subprocess.run(["git", "pull"])
    subprocess.run(["systemctl", "restart", "myapp"])

The Pi never needs an open port. It polls out, picks up the deploy job, and runs it.

The Python SDK

pip install intent-bus

from intent_bus import IntentClient

bus = IntentClient()  # reads key from ~/.apikey automatically

# From your cloud script
bus.publish(goal="send_notification", payload={"message": "Done"})

# On your phone/Pi/worker machine
def handle(payload):
    os.system(f"termux-notification --content '{payload['message']}'")

bus.listen(goal="send_notification", handler=handle)

What This Doesn't Do

Be honest about limitations:

Not for high-frequency workloads — SQLite serializes writes, ceiling around 50-100/sec
Not exactly-once delivery — at-least-once, workers should be idempotent
Not multi-region — single SQLite node, no replication
Not a Firebase replacement — no real-time push, no client SDKs

It's designed for the gap between cron scripts and full distributed systems. Scripts, bots, scrapers, phone notifications, home automation — workloads where Redis is overkill and cron is too dumb.