Chapter 3 — The Extension Model: Vlahx as a Runtime for Independent Applications

1. From Features to Applications

As we saw in the previous chapter, Vlahx Core provides configuration, extension loading, registration, hooks, events, and runtime management.

But there is a deeper architectural idea behind the extension system.

Vlahx is not simply an application with plugins attached to it.

It is an environment in which extensions can become independent applications.

This distinction is important.

A traditional application architecture often starts with a central database, a central set of models, and a central collection of features. As the application grows, new features are added to the same structures until the original Core gradually becomes responsible for almost everything.

Vlahx takes a different approach.

The Core remains relatively small. It provides the environment in which extensions can operate, while the extensions remain responsible for their own functionality.

                         VLAHX CORE
                             │
                provides the runtime
                             │
          ┌──────────────────┼──────────────────┐
          ↓                  ↓                  ↓
      Integration         Services          Lifecycle
       contracts         and APIs           management
          │                  │                  │
          └──────────────────┼──────────────────┘
                             ↓
                         EXTENSION
                             │
              ┌──────────────┼──────────────┐
              ↓              ↓              ↓
          own logic       own routes      own data
              │              │              │
              └──────────────┼──────────────┘
                             ↓
                    Independent application
                    inside Vlahx runtime

The Core provides the ground.

The extension builds on it.

2. The Vlahx Integration Contract

For an extension to become part of Vlahx, it does not need to be rewritten as part of the Core.

It needs to respect the integration contract defined by the platform.

At its simplest level, the contract allows Vlahx to discover the extension, understand its metadata, load its code, and call its registration entry point.

plugin.json
     │
     ↓
  Discovery
     │
     ↓
  Metadata
     │
     ↓
plugin.py
     │
     ↓
  register()
     │
     ↓
Vlahx Runtime

This contract is deliberately small.

Once the extension has been loaded, what happens inside that extension is largely its own concern.

A plugin can contain Python services, FastAPI routes, database models, background tasks, APIs, templates, JavaScript, scheduled jobs, authentication logic, business logic, or any other functionality required by its purpose.

The Core does not need to understand all of these things in advance.

It only needs to provide the mechanisms through which the extension becomes part of the running application.

In other words:

Vlahx defines how an extension enters the runtime, not what the extension must become.

3. The Core Is Intentionally Small

This philosophy also applies to persistent data.

Vlahx does not attempt to place every piece of application data into one enormous central database.

The Core has its own database, app.db, but its purpose is intentionally limited to data that belongs to the Vlahx platform itself.

Extensions can maintain their own databases.

/db
│
├── app.db
├── blog.db
├── shop.db
├── analytics.db
├── newsletter.db
├── robots_sitemap.db
├── share.db
├── telegram_notify.db
├── vlahx_ai_author.db
└── vlahx_oauth.db

This is not just a convenient way of organizing files.

It is an architectural boundary.

The Blog plugin can own blog.db.

The Shop plugin can own shop.db.

The OAuth plugin can own vlahx_oauth.db.

The AI Author plugin can own vlahx_ai_author.db.

Each extension is therefore free to define the data model required by its own functionality.

The Core does not need to know every table, every relationship, or every business rule belonging to every extension.

4. One Runtime, Multiple Data Domains

The result is an architecture where multiple applications can operate inside the same Vlahx runtime while keeping their persistent data separated.

                         VLAHX RUNTIME
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
        Core                Blog                Shop
          │                   │                   │
          ↓                   ↓                   ↓
       app.db              blog.db             shop.db
          │                   │                   │
      Core data          Blog data          Shop data

Each extension can therefore have its own data domain.

This becomes particularly useful when an extension grows beyond a simple feature.

For example, an extension may eventually need:

• its own users
• its own roles
• its own permissions
• its own configuration
• its own content
• its own business entities
• its own logs or history
• its own APIs

There is no architectural requirement that all of this must be moved into app.db.

The extension can create the tables it needs in its own database.

Even an extension-specific users table is perfectly valid when the application represented by that extension has its own identity model.

This is one of the mechanisms that allows an extension to remain genuinely independent.

5. The /app and /db Boundary

There is another important detail in the Vlahx deployment architecture.

The database directory is not part of the application source tree.

VLAHX DEPLOYMENT
│
├── /app
│   │
│   ├── core/
│   ├── plugins/
│   ├── themes/
│   ├── templates/
│   └── main.py
│
└── /db
    │
    ├── app.db
    ├── blog.db
    ├── shop.db
    ├── analytics.db
    └── ...

The distinction is deliberate.

/app contains the application code.

/db contains persistent application state.

In Docker deployments, /db is mounted as a separate data volume rather than being embedded into the application image.

                 DOCKER CONTAINER
              ┌─────────────────────┐
              │                     │
              │       /app          │
              │                     │
              │   Vlahx source      │
              │   Core              │
              │   Plugins           │
              │   Themes            │
              │                     │
              └──────────┬──────────┘
                         │
                         │ mounted data
                         ↓
              ┌─────────────────────┐
              │       /db           │
              │                     │
              │   app.db            │
              │   blog.db           │
              │   shop.db            │
              │   ...                │
              │                     │
              └─────────────────────┘
                     PERSISTENT
                      STORAGE

This means that rebuilding or replacing the application image does not mean rebuilding the application's persistent data.

The code and the data have different lifecycles.

Code can be replaced. Data must persist.

This separation is especially valuable for a modular platform because extensions can evolve independently from the storage containing their data.

6. A Plugin Can Be Much More Than a Feature

Consider a hypothetical plugin that provides a complete reservation system.

From the Vlahx perspective, the plugin might simply be another extension loaded through plugin.py.

Inside the plugin, however, there could be an entire application:

reservation/
│
├── plugin.py
├── plugin.json
├── routes.py
├── services.py
├── models.py
├── database.py
├── auth.py
├── scheduler.py
├── templates/
├── static/
└── ...
             │
             ↓
       reservation.db
             │
       ┌─────┼─────┐
       ↓     ↓     ↓
    users bookings resources

Vlahx does not need to turn every one of those components into Core functionality.

The plugin can own them.

The Core provides the environment in which they can run.

This is the point where the word plugin becomes slightly misleading.

Some extensions really are small plugins.

Others can become almost complete applications.

Both can use the same integration mechanism.

7. Extensions Can Also Participate in the Core

This does not mean that extensions are completely isolated from Vlahx.

When an extension needs to contribute something to the platform itself, Vlahx provides explicit integration points.

Hooks, events, providers, and APIs allow an extension to participate in Core-level behavior without requiring the Core to know the internal implementation of that extension.

                    VLAHX CORE
                         │
             ┌───────────┼───────────┐
             ↓           ↓           ↓
           Hooks       Events     Providers
             │           │           │
             └───────────┼───────────┘
                         ↓
                     EXTENSION
                         │
                  contributes back
                         │
                         ↓
                    Core behavior

This is where plugins such as sitemap or robots can be useful examples.

They are not representative of the fundamental purpose of the plugin architecture. They are examples of extensions that choose to participate in a Core-level capability.

The important distinction is:

Participation is optional. Integration is required.

Every extension must integrate with the runtime.

Not every extension needs to provide functionality back to the Core.

8. The Core Does Not Need to Know the Future

This architecture solves a fundamental problem in extensible software.

When the Core is responsible for every possible future feature, the Core must constantly grow in order to anticipate what developers might want to build.

That creates increasing coupling.

Vlahx takes the opposite approach.

Traditional approach

CORE
 │
 ├── Blog
 ├── Shop
 ├── Analytics
 ├── OAuth
 ├── AI
 ├── Newsletter
 ├── ...
 └── future feature?
          ↓
      modify Core


Vlahx approach

                    CORE
                      │
             integration contract
                      │
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
     Blog           Shop          Future
       │              │              │
    blog.db        shop.db       own.db
       │              │              │
       └──────────────┼──────────────┘
                      ↓
               Vlahx Runtime

The Core therefore does not have to predict every application that might eventually run on Vlahx.

It only needs to maintain a stable and useful integration environment.

This makes the architecture open-ended.

As long as an extension can satisfy the integration contract and operate within the resources and permissions available to it, its internal functionality can evolve independently.

9. The Extension Owns Its Domain

A useful way to think about this architecture is through ownership.

VLAHX CORE
│
├── owns Core runtime
├── owns Core configuration
├── owns Core lifecycle
└── owns Core data
        │
        │ integration contract
        ↓
EXTENSION
│
├── owns its logic
├── owns its services
├── owns its routes
├── owns its data model
├── owns its database
└── owns its application behavior

The extension does not become a second Core.

It becomes an independent domain operating inside the Vlahx runtime.

This separation makes the architecture easier to reason about because ownership remains visible.

If something belongs to the Blog application, the Blog extension can own it.

If something belongs to the Shop application, the Shop extension can own it.

If something belongs to Vlahx itself, it belongs in the Core.

The boundary does not have to be perfect from the first day. It can evolve as the platform evolves.

10. The Real Meaning of “Extend It”

The Vlahx philosophy is often summarized by the phrase:

Extend it. Share it. Vlahx it.

In the context of the architecture described in this chapter, “Extend it” has a very specific meaning.

It does not mean:

“Add another feature to the Vlahx Core.”

It means:

“Build something that can live inside the Vlahx runtime without becoming part of the Core itself.”

The Core provides the ground.

The extension brings the application.

The extension can bring its own logic, its own data model, and even its own identity system when required.

And when it needs to communicate with the platform, Vlahx provides explicit mechanisms for doing so.

                       VLAHX ENGINE
                            │
                   integration contract
                            │
             ┌──────────────┴──────────────┐
             │                             │
        CORE INFRASTRUCTURE           EXTENSION
             │                             │
       ┌─────┼─────┐               ┌──────┼──────┐
       ↓     ↓     ↓               ↓      ↓      ↓
    Runtime Hooks Events         Logic  Routes  Data
       │     │     │               │      │      │
       └─────┼─────┘               └──────┼──────┘
             │                            │
             ↓                            ↓
        Vlahx Core                  Independent
                                    application
                                          │
                                          ↓
                                     own database
```

That is the real extension model.

Conclusion

Vlahx Core is intentionally narrow.

It does not attempt to own every feature, every table, or every application that may run on the platform.

Instead, it provides the infrastructure required for independent extensions to operate as part of a common runtime.

The extension contract connects the application to Vlahx.

The extension can then own its functionality and its persistent data.

The separate /db volume keeps that persistent state outside the application source tree and allows the code and data to follow different lifecycles.

Hooks, events, providers, and APIs provide controlled ways for extensions to participate in platform-level behavior when necessary.

The result is not simply a plugin architecture.

It is a runtime architecture in which the Core provides the environment and extensions provide the applications.

        CONFIGURATION
              +
       RUNTIME INFRASTRUCTURE
              +
       INTEGRATION CONTRACT
              │
              ↓
        ┌───────────────┐
        │ VLAHX ENGINE  │
        └───────┬───────┘
                │
       ┌────────┼────────┐
       ↓        ↓        ↓
     Blog      Shop     AI Author
       │        │        │
   blog.db   shop.db   ai_author.db
       │        │        │
       └────────┼────────┘
                ↓
        INDEPENDENT
        APPLICATIONS
        INSIDE ONE
        VLAHX RUNTIME

And this gives us the natural next step.

So far, we have looked at how Vlahx starts, how the Core builds its runtime, and how independent extensions become applications inside that runtime.

Now we can look at how that runtime becomes a web interface.

That is where templates, themes, loaders, rendering, and the frontend architecture enter the picture.