Skip to content
Alex ALAVO

Engineering Case Study · Instagram Automation Platform

Coordinating browser automation, real-time monitoring and multi-account execution

A web-controlled automation platform manages multiple persistent Instagram browser sessions, parallel workflows, cooldowns, account status detection and real-time logs.

Role
Python architecture, browser automation, concurrency design, dashboard implementation, persistence, debugging tools and client documentation.

System Responsibilities

  • Automation
  • AI Integration

Technologies

  • Python
  • Flask
  • Socket.IO
  • Playwright
  • AsyncIO
  • SQLite
  • OpenAI Vision

Verified Evidence

7 verified results documented below.

Overview

Operators needed to run several accounts independently from a web interface, with authenticated sessions preserved, cooldowns respected and account health visible in real time.

  • Operate several accounts independently.
  • Preserve authenticated browser sessions.
  • Control automation from a web interface.
  • Stream logs in real time.
  • Respect cooldowns and daily limits.
  • Detect suspended or disabled accounts.
  • Support multiple client import formats.

The problem

Multi-account browser automation becomes unstable when browser sessions, web-server threads and asynchronous tasks compete for control. The system also needed resilient selectors, persistent state and operator visibility.

Constraints that shaped the system

  • Flask and Socket.IO operate in a different concurrency model from async Playwright.
  • Browser interfaces change.
  • Account sessions require isolation.
  • Operators need stop controls.
  • Automation state must survive restarts.
  • Client account data arrives in inconsistent formats.

System architecture

Flask and Socket.IO provide the control plane, while isolated worker threads own independent asyncio event loops for browser workflows. SQLite stores operational state, persistent browser directories preserve sessions and callback-based logging connects workers to the dashboard.

System architecture diagram: Operator Dashboard, Flask + Socket.IO Control Plane, Automation Worker Thread, Playwright Browser Session, SQLite State Store, Callback Logger.

client

Operator Dashboard

Key engineering decisions

Isolate event loops by worker

Accepted

Flask and Socket.IO operate in a different concurrency model from async Playwright.

Each automation worker owns its asyncio loop inside a dedicated thread.

Why

  • Avoid cross-loop Playwright errors.
  • Keep the web control plane responsive.
  • Isolate account failures.

External selector registry

Accepted

Browser interfaces change, and scattering selectors across scripts makes maintenance fragile.

Store ordered selectors in JSON instead of scattering them across scripts.

Why

  • Centralized maintenance.
  • Stable selectors prioritized first.
  • Easier debugging and fallback behavior.

Alternatives considered

  • Selectors scattered directly across automation scripts

Persistent sessions

Accepted

Account sessions require isolation, and automation state must survive restarts.

Give each account its own Chromium data directory.

Why

  • Reduce repeated login.
  • Isolate cookies and state.
  • Support manual recovery.

Implementation highlights

  • Human-like interaction utilities.
  • Cooldown and contact history.
  • Multi-format account import.
  • Optional story understanding through vision models.
  • Six operational modules.
  • Windows and VPS deployment scripts.
  • Extensive architecture and client documentation.

Quality and operations

Testing

  • Pytest coverage for core logic.
  • Dedicated debugging utilities.

Operations

  • Stop event shared safely with workers.
  • Real-time callback logs.
  • Detection of suspended and disabled states.

Results and evidence

  • Implementation fact

    Isolated asyncio event loop per worker thread

  • Implementation fact

    Persistent Chromium sessions per account

  • Implementation fact

    Externalized selector strategy

  • Verified metric

    Operational modules6

  • Observable capability

    Real-time operational logs

  • Implementation fact

    Windows and VPS deployment scripts

  • Implementation fact

    Client documentation delivered

Lessons from the system

  • Concurrency boundaries must be explicit.
  • Browser automation requires observability and recovery tooling.
  • Selector strategy is a maintainability concern, not a minor implementation detail.

Continue exploring

LeBonDon

Designing a tested multi-role platform for inventory, exchange and social distribution

LeBonDon manages stock, exchanges and distribution between associations, companies and beneficiaries. Its LeBonDestock module creates a complete B2B flow for discounted unsold inventory.