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

Overview

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.

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

Thanks for taking a look.
Top comments (0)