I built EverSpark Forge: a modular AI creation and orchestration system

J hin — Sat, 26 Sep 2026 14:20:23 +0000

EverSpark Forge is a modular AI creation and orchestration system.

I started building it because I was tired of repeatedly setting up the same AI environment whenever I switched machines, rented a new cloud GPU, or rebuilt a workspace.

At first, it was just a collection of deployment and automation scripts.

Over time, it gradually became a larger system for connecting AI models, workflows, execution backends, runtime environments, storage, and management tools behind one unified architecture.

What EverSpark Forge does

The main goal is to make different AI capabilities work together without tightly coupling the entire system to one model provider, one image backend, or one machine.

Current capabilities include:

a unified WebUI
local Ollama model backends
OpenAI-compatible model backends
ComfyUI image execution
Diffusers image execution
natural-language-to-image workflows
reusable character templates
model and backend switching
runtime and service management
cloud GPU deployment workflows
configuration workflows
storage, backup, and recovery tools

The system is still under active development, and new modules are being added continuously.

The orchestration idea

One of the most important parts of EverSpark Forge is the orchestration layer.

The Orchestrator is not supposed to know how every backend works internally.

It should not care whether a task is ultimately executed by Ollama, an OpenAI-compatible API, ComfyUI, Diffusers, or something else.

Its job is to decide what needs to happen and send standardized tasks to the appropriate module.

The backend-specific modules handle their own protocols, request formats, execution logic, and responses.

This means that if a provider changes its API, or if I want to add another execution backend, I should only need to modify or add the corresponding module instead of redesigning the whole system.

That separation is one of the core architectural ideas behind EverSpark Forge.

Modular by design

I want the major parts of the system to remain replaceable.

For example:

Concept Forge handles language-model-related tasks
Image Forge handles image-generation execution
Runtime handles service and environment state
Storage handles persistence, backup, and recovery
the Orchestrator connects these capabilities together

The exact implementation behind each module can change without requiring the rest of the system to understand every implementation detail.

EverSpark Forge is also self-hostable and open source, but I see those as properties of the system rather than its entire identity.

Demo

I recorded a full demo showing the core workflow, including deployment, WebUI usage, natural-language image generation, character templates, model switching, and configuration flows.

The project has continued evolving since the demo was recorded, so the video does not include every feature currently available.

For the latest functionality, the repository and documentation should be treated as the source of truth.

Demo:
[YouTube link]

GitHub:
[GitHub repository link]

Why I’m sharing it now

For a long time, I kept adding “just one more feature” before publishing it.

Eventually I realized that if I kept waiting for the system to feel completely finished, I might never actually release it.

So I’m publishing EverSpark Forge while it is still actively evolving.

I’d especially appreciate feedback on:

the overall system architecture
the orchestration layer
backend abstraction boundaries
deployment workflows
how replaceable the individual modules feel
what you would expect from a system like this