Skip to content

VirtualForge

VirtualForge is our integration cloud — the intelligent connectivity engine behind everything we build.

It is cloud-native and technology-agnostic, and it coordinates interactions between your services (historians, ERP and MES, partner platforms like Seeq) and the edge (IoT, process equipment, instrumentation). Then it adds the layer that makes a connection meaningful — logic, context, and metadata — and runs the work performed on top of it: formulas, algorithms, and models delivered as Tools. Around the office we call it the API in the sky, which describes it better than the formal wording does.

VirtualForge is hosted and operated by Endeavor Engineering as a managed cloud service on AWS. It is multi-tenant, with customer data isolated at the storage layer rather than by application filtering.

In this section

  • Plugin architecture

    How capability is added to the platform — isolation, packaging, and the contribution model that will open to partners over time.

  • Bring Your Algorithm to the Forge

    For an outside author with working code: delivering it as an API-based product on the platform, and what a collaboration between us would look like.

  • Connectors ++

    The production-grade capability set that rides along on every EEI connector.

  • Operational events and notifications

    One event shape, one set of routing rules, and adapters to the chat, alerting and incident tools you already use. Running our own operations today.

  • Products

    ForgeVault, Plot Digitizer, ForgeIQ, and the VirtualForge Toolbox — what each one is, and what is shipping versus coming.

An enabler, not a product

VirtualForge is worth being precise about, because it is easy to assume it is the thing you buy.

It is the enabler. You buy connectors and tools; they run on VirtualForge, and they are better because of it. Some of what we talk about most — VirtualForge itself, and Connectors ++ — are enablers in exactly this sense: they are the reason the products are good, not separate line items you evaluate on their own.

That layering is deliberate:

Layer What it is
VirtualForge The platform — connectivity, coordination, and the intelligence layer
Connectors ++ The shared capability set every EEI connector inherits
Tools The delivered units of capability — connectors, processors, outputs, data platforms

The consequence worth understanding: when you engage EEI you are not buying one integration, you are buying the foundation under all of them. The next connector is faster, and arrives at the same operational quality as the last, because the hard parts were solved once.

Where the platform actually stands

We would rather be straight about this than have you find out later.

An early version of VirtualForge was built and deployed for specific use cases — hand-built, quickly, to prove the idea worked. It did. It was also a proof of concept, with the shortcuts that implies, so we deliberately stopped developing it rather than making a temporary design permanent.

The platform today is a ground-up rebuild: AI-assisted development against fully expressed engineering methodology, which is how a company our size delivers at a pace that would otherwise be implausible. Throughout that work, the layer above the platform has kept shipping — individual VirtualForge connectors and tools are in customer production now.

Both of these are true, and we try to say both:

  • Our connectors are built on VirtualForge today, and are delivered and supported as products.
  • The broader platform — the full service surface, the self-service experience, the marketplace — is being rebuilt, not merely planned.

Each product page states its own status in plain terms, using four words we mean literally. If a specific capability matters to a decision you are making, ask us where it stands and we will answer specifically.

Working with VirtualForge

Three surfaces, each suited to different work:

Surface What it is for
ForgeIQ — the portal Your interface to the platform: signing in, setting up your organization, managing entitlement and licensing, configuring what you own, and seeing what it is doing on your behalf. Connectors are the initial focus
The command line Operating the platform and its data services — provisioning, data movement, deployment, and entitlement tasks that belong in a script rather than a screen
APIs and SDKs Building against the platform directly. Every platform capability is reachable programmatically; the SDKs are how connectors and tools are built

The command line is worth a note on direction. It exists today, as vf, and is how we operate the platform and ForgeVault deployments. Where it is going is a resident CLI inside the VirtualForge cloud — the same pattern the major clouds settled on, where the shell is part of the platform and comes pre-authenticated with your context rather than being something you install and configure. A local client for people who prefer their own terminal is a later step.

That progression matters more than it might appear: a platform you can only reach through a UI is a platform you cannot automate, and industrial operations run on repeatable procedures rather than remembered clicks.

Extensible by design

VirtualForge is built on a plugin model: new capability is added without modifying core platform code. Plugins are isolated from the core and from each other, so a plugin failure cannot take the platform down with it, and capability can be deployed or updated without a platform release.

Today that path is used by EEI's own engineers to build and deploy tools. It is designed to open to partners and third parties as the platform matures — growing the capability surface faster than any one company could on its own. The mechanics, and an honest account of which parts exist today, are in plugin architecture.

If you own an algorithm or a body of working code and want it delivered as an API-based product, Bring Your Algorithm to the Forge is the detailed version — the technical shape, what each side brings, and how an arrangement can be structured.

Where it is headed

Stated as direction rather than commitment:

  • Connected intelligence at scale — extracting new value from systems you already own, by bridging gaps with logic, context, and enrichment.
  • A service marketplace — composing the platform capabilities you need rather than taking a monolith.
  • Industrial data intelligence — not just storage and retrieval, but insight, anomaly detection, and AI-assisted analysis.
  • Multi-cloud portability — AWS-primary today; the architecture keeps the option open.
  • A partner ecosystem — co-creating specialized solutions with technology partners.