Today I want to write about Antsand. If you have been reading ShivasNotes and wondering how the posts actually get published, how the site is structured, or what the platform underneath is — this is that post. Antsand is not a third-party tool I am using. It is mine. I built it, I run it, I break it, and I keep fixing it.

The short version: Antsand is a full-stack web platform built on PHP, Phalcon, and HMVC modules, with a polyglot database layer (MySQL + MongoDB), structured content contracts, a website builder called Databoard, and a publishing and deployment system I use every single day. It powers this blog, several client sites, and — in the direction I am building toward — will eventually be the data and compute surface that connects sensor hardware, federated AI training, and CKE-generated kernels into one coherent loop.

I am treating this as a research note rather than a marketing page: the claims below come from a live system that I operate, not from a hypothetical architecture diagram.

That is a lot to explain. Let me start from the beginning.

Why I Built It

I did not build Antsand to compete with WordPress, Webflow, or Substack. Those tools are useful for what they do. I built Antsand because every time I tried to use someone else's platform for real engineering work, I hit the same wall: I could not own the data model, the rendering model, the deployment model, or the APIs at the same time. I could pick two or three, but never all of them.

What I actually wanted was a system where I could describe a website as structured data and have the platform assemble the site from that description. Where I could run a publishing API and have agents, scripts, and my own tooling talk to it without workarounds. Where the content was mine in a database I controlled, not locked in someone's cloud. Where I could add a new module — a sensor dashboard, a training observatory, an ecommerce flow — without fighting the architecture of the underlying tool.

Over fourteen years, that idea slowly became a real system. It was not fast. It was not clean. But it survived because I kept using it, and real use eventually turns an experiment into infrastructure.

What Antsand Was: The Fourteen-Year Slog

The earliest version of Antsand was just a content management system. Then it became a website builder. Then it grew authentication, groups, multi-tenancy, ecommerce, forms, profiles, and a client deployment system. Then it picked up a publishing API, a structured content model called Databoard, and the module hierarchy that makes it possible to add features without destroying what already works.

Fourteen years sounds long. It is long. But a real platform is not a landing page or a database table. It slowly becomes the sum of every operational detail you cannot skip: users, permissions, assets, broken migrations, changing deployment environments, client projects with conflicting requirements, and the need to keep the live site up while the platform underneath it evolves.

Antsand is now at a point where I can say it is infrastructure. It runs live websites. It runs ShivasNotes. It has a stable API surface. And it has an architecture that can scale in directions I could not have planned for at the start.

What Antsand Is Now

The current system is a full-stack PHP platform built on Phalcon with HMVC module organization. The reason I chose PHP and Phalcon is boring and correct: PHP is widely deployable, fast enough, and very good at server-side HTML rendering. Phalcon is compiled as a C extension, so the framework itself has essentially zero overhead. And HMVC matters because Antsand is not one small app — it is a collection of surfaces that need to share users, groups, assets, and deployment rules without becoming a tangled monolith.

Antsand modules (current)
  backend/login         — authentication, sessions, ACL
  backend/databoard     — website builder and structured content
  backend/notes         — ShivasNotes blog and publishing
  backend/groups        — multi-tenant organizations
  backend/sales         — sales and lead workflows
  backend/ecommerce     — product catalog and transactions
  frontend/public       — generated public-facing sites
  generated/hmvc-sites  — deployed federated websites

Databoard: The Website-As-Data Idea

The heart of Antsand is Databoard. Databoard is the control surface where a website is represented as structured data: pages, sections, content fields, CSS classes, menus, routes, deployment settings, and module configuration. The point is not that every website looks the same. The point is that every website has a predictable object shape underneath it.

Databoard object
  -> pages
  -> sections (header / body / footer contract)
  -> CSS class contracts
  -> HMVC routes and controllers
  -> generated Volt views
  -> deployment settings
  -> public URL

The section shape — header, body, footer — is one of the most useful ideas in the platform. Most web sections have the same skeleton: a heading or intro, some body content, and a call-to-action or supporting link. By making that shape explicit and building templates around it, Antsand can render clean pages from structured data without writing bespoke HTML for every section. It also makes the system legible to agents: an AI editing a Databoard object knows where headings, paragraphs, images, repeated items, and CTAs belong, because the contract says so.

Polyglot Persistence: MySQL + MongoDB

Antsand uses two databases for a deliberate reason: MySQL for identity and relationships, MongoDB for dynamic content.

• MySQL handles users, groups, permissions, and relational structure. ACID guarantees matter here because a permission bug is a security bug.
• MongoDB handles Databoard configurations, course content, ecommerce products, and anything with a flexible or nested schema. Adding a new section type to Databoard is a data change, not an ALTER TABLE.

This split is not complexity for its own sake. It is the same pattern that Netflix, LinkedIn, and most serious production platforms use: let each storage technology do what it does well, draw clear data boundaries, and do not mix identity with content.

ZMQ: The Sensor and Real-Time Layer

This is the piece most people do not expect in a web platform. Antsand already has a ZMQ integration layer in production. ZMQ is a message-passing library that makes it possible for hardware sensors, microcontrollers, and field command centers to push data into the platform in real time.

Sensor / MCU (ESP32, Raspberry Pi)
  -> ZMQ PUB socket (tcp://*:5555)
  -> PHP ZMQ extension via Phalcon DI
  -> MongoDB (time-series storage)
  -> WebSocket (real-time dashboard updates)
  -> Nginx (proxied to browser)

This exists because the longer arc of Antsand is not just publishing. It is also the control and data surface for field hardware: environmental sensors, TDR bog monitors, and eventually drone telemetry from the AntShiv Robotics work. The ZMQ layer is already in the Phalcon DI system. What is not yet fully wired is the pipeline from that data into training workflows.

Federated Deployment: 35 Sites, One Platform

Antsand currently runs 35 deployed sites from a single platform codebase. Each site can be a fully autonomous HMVC website with its own routes, templates, styles, and content, but sharing the same module infrastructure for users, assets, permissions, and deployment. The performance baseline is about 9 ms per page response — roughly 13 times faster than a typical WordPress install — because the Phalcon C extension and lean server-rendered architecture do not add framework weight at runtime.

Where Antsand Is Going: Three Surfaces

The current platform is Phase 0: a content and publishing platform. What I am building toward is a three-phase architecture where the structured data foundation that already exists becomes the base for two more surfaces — a data and training surface, and eventually a full AI infrastructure layer.

content → data → training → compute

Phase 0: Content and Publishing (Now)

This is what is live today. Antsand runs ShivasNotes, the publishing API I use every day, the Databoard website builder, the Groups module for multi-tenant organizations, ecommerce and form workflows, and 35 deployed sites. Every post on ShivasNotes goes through the Antsand publishing API. The carousel images are generated locally and uploaded through the same API. The note metadata, tags, slugs, and asset URLs are all structured objects in the Antsand database.

This is also the phase that hardened the architecture. Fourteen years of real use forced the data contracts, the deployment model, the module boundaries, and the permission system to actually work — not just look correct in a diagram.

Phase 1: Data and Training Surface (Building)

The next surface turns Antsand into a data platform as well as a content platform. This is already partially built. The ZMQ layer is in the Phalcon DI system. MongoDB is already the flexible store. The Databoard permission model already supports multi-tenant data access.

What Phase 1 adds on top of that is the pipeline from raw data to training-ready datasets:

• Sensor ingestion: ZMQ → PHP → MongoDB for real-time environmental data from ESP32 sensors, drone telemetry, and field command centers.
• Governed datasets: content, decisions, experiments, and field records organized into permission-aware datasets for retrieval, fine-tuning, or evaluation — without sending the data to a third-party cloud.
• Training job orchestration: submitting CKE training jobs, tracking progress, and reporting results back into Antsand dashboards in real time.
• Agentic publishing loop: AI coding agents (the same ones already running CKE work) connecting to the Antsand API to draft, publish, and update posts without a human in the loop for routine documentation.

Phase 1 data flow
  field sensor (ESP32)
    -> ZMQ PUB socket
    -> Phalcon ZMQ subscriber
    -> MongoDB (time-series)
    -> Antsand dashboard (WebSocket)
    -> governed dataset (training pipeline)
    -> CKE training job (SLURM or local HPC)
    -> trained weights -> edge deployment

Phase 2: Full AI Infrastructure (Vision)

Phase 2 is the full vision: Antsand as the orchestration layer for sovereign CPU AI. Not a GPU cloud. Not a managed ML platform. A system where an organization owns its data, owns its compute, owns its model, and uses Antsand as the surface that ties them together.

In this phase, C-Kernel-Engine is the compile layer. It takes a model graph and produces explicit C kernels that run on the organization's own CPUs. Antsand manages the training jobs, the dataset governance, the model versioning, and the deployment to edge devices (drones, field sensors, embedded inference nodes). The federated deployment system Antsand already uses for websites becomes the same system that deploys trained models to field hardware.

Phase 2 architecture
  Antsand (orchestration + data surface)
    -> governed org dataset
    -> CKE compiler (model graph -> C kernels)
    -> federated CPU training (multi-node Xeon)
    -> trained .bin weights
    -> edge deployment (drone, ESP32, TDA4VM)
    -> real-time inference results
    -> Antsand dashboard (researcher view)

The reason this architecture can work is not that any single piece is novel. It is that the same structured data layer, permissions model, and deployment system that already runs 35 websites also understands how to govern data, schedule jobs, and deploy artifacts. The extension is real work, but it is not a rewrite.

How Antsand and CKE Connect

C-Kernel-Engine and Antsand are different projects at different layers, but they share the same instinct: make the structure explicit, keep the contracts visible, generate what can be generated, and retain enough control to debug the system when it breaks.

Antsand
  structured website / dataset data
    -> generated website / governed dataset

C-Kernel-Engine
  model graph + kernel contracts + memory plan
    -> generated C runtime

Right now the connection is mostly publishing: CKE work gets documented on ShivasNotes, which runs on Antsand. But in Phase 1 and Phase 2, the connection becomes operational. Antsand submits the training jobs. CKE executes them. The introspection data — gradient values, memory allocation, parity checks — comes back into Antsand's dashboards. The trained artifacts go out through Antsand's deployment system. The platform becomes the management layer for the compiler.

Why PHP and Phalcon Still Make Sense

I get this question often. Why not rewrite in Go or Rust? Why not use a framework with a larger community?

The answer is pragmatic. PHP with Phalcon (compiled as a C extension) delivers 9 ms page responses without a build step, a node runtime, or a container full of JavaScript dependencies. Phalcon is not copied into each site as framework baggage — it lives once in the runtime, so the deployed site mostly carries application code and content, not duplicated framework logic. The framework enforces HMVC discipline: modules are isolated, the dependency injection container is explicit, and there is no magic behind the scenes. Adding a new module does not require changing the existing ones. And after fourteen years, I understand this codebase well enough to move fast without constantly fighting the tool.

The IoT angle also matters here. The runtime footprint stays small, which matters when Antsand generates many sites and when those sites need to run on resource-constrained field hardware as federated nodes, not just cloud servers. That keeps the system centered on application code and deployment data instead of carrying a heavy framework stack everywhere.

What This Means for ShivasNotes

ShivasNotes is not just a blog theme running on Antsand. It is the public archive of a technical system documenting another technical system. Every post is a structured note object with metadata, assets, tags, and a slug, published through an API that I wrote and control. The carousel images are generated locally and uploaded through that same API. The publishing scripts I run every day are part of the same pipeline that will eventually submit training jobs to CKE.

That is the bet behind Antsand. If the publishing pipeline is low-friction, real work gets documented consistently. If the documentation compounds, the archive becomes a technical memory system. If the same structured data layer that holds the notes also holds sensor data and training artifacts, the platform becomes something more than a blog host.

The Takeaway

Antsand took fourteen years because a real platform is not a landing page. It is the sum of every operational detail you cannot skip. It is now a full-stack web platform running live websites and a daily publishing workflow. It is designed — in the architecture it already has, not in plans — to grow into a data surface, an agentic surface, and eventually a training and compute surface connected to C-Kernel-Engine and field hardware.

The next posts in this series will go deeper into specific layers: how Databoard assembles websites, how the federated deployment works, how the ZMQ sensor layer connects to MongoDB, and how the CKE training observatory will eventually live inside Antsand dashboards.