Generating Live Ext JS Database Applications with Indi Engine AI: A Practical Architecture for Enterprise Modernization

Modernizing enterprise applications is rarely a matter of replacing an old interface with a new one.

The deeper challenge is preserving the data structures, business rules, permissions, workflows, and operational behavior that have accumulated around enterprise databases over many years – while giving users a modern web experience.

For software architects, that creates a familiar problem: how do you turn an existing relational database into a modern, responsive application without rebuilding the entire front end, API layer, state-management model, and administrative infrastructure from scratch?

Indi Engine AI takes a different approach.

The platform connects directly to existing SQL Server and PostgreSQL environments, analyzes their database structures, generates an Ext JS application design, and provides zero-code controls for refining the resulting interface. It also incorporates real-time synchronization, containerized deployment, database access controls, automated maintenance, and backup infrastructure into the same platform.

The result is an architectural model that moves database modernization away from a conventional “rebuild everything” approach and toward a more automated, metadata-driven application-generation model.

The Enterprise Database Modernization Problem

Legacy enterprise databases are often not the primary problem.

They continue to hold valuable operational data, established relationships, business rules, permissions, and processes. The challenge is exposing that infrastructure through a modern application experience without disrupting the underlying system.

Traditionally, this requires teams to manually build:

• Front-end components
• Data grids and forms
• API endpoints
• Database access layers
• State management
• Permission models
• Relationship navigation
• Real-time update mechanisms
• Administrative interfaces
• Deployment infrastructure

That work can take months before users see meaningful application functionality.

A database application generator changes the economics of that process by treating the existing database schema as the starting point for application generation.

Indi Engine AI is built around this model. Introduced at JS Days 2026 by founder and developer Pavel Perminov, the platform is positioned as a 5-in-1 database application development platform, bringing database operations, configurable hierarchies, roles and permissions, real-time synchronization, containerized deployment, and backup management into one environment.

From Database Schema to Working Ext JS Application

The central architectural idea is straightforward:

Start with the database that already exists instead of recreating its structure inside a new application stack.

Indi Engine AI can connect to external database environments such as:

• Microsoft SQL Server hosted through AWS RDS
• PostgreSQL hosted through Supabase
• Other supported database environments

After authentication, the platform examines the database structure and extracts information about entities, fields, relationships, roles, permissions, and data types.

That information is serialized into a vendor-agnostic JSON Source Meta Snapshot.

The snapshot then becomes the foundation for generating an Ext JS application design.

This creates a pipeline that can be represented as:

Existing Database → Schema Extraction → Metadata Snapshot → Ext JS Application Design

The architectural advantage is that the application design is derived from the actual database structure rather than manually recreated by a development team.

A Hybrid Database Client for Multiple Projects

Indi Engine AI is not limited to a single database connection.

A deployed engine instance can operate as a hybrid database client, allowing developers and administrators to connect to multiple external databases and maintain different application design projects without modifying the schemas of those target databases.

This separation is important in enterprise environments.

The database remains the system of record, while the generated application becomes a configurable interface and operational layer on top of it.

Teams can therefore work with different application projects while keeping the underlying database structures independent.

A Containerized Architecture Built for Operational Control

Application generation is only useful if the resulting environment can be deployed and operated reliably.

Indi Engine AI uses a Docker-based architecture consisting of four primary containers:

This separation establishes clear boundaries between the public-facing application, privileged host operations, background processing, and database infrastructure.

For enterprise teams, that distinction matters.

Administrative operations should not require the primary web process to have unrestricted access to the underlying host environment.

Deploying the Platform with Docker

The deployment workflow is designed to be relatively lightweight.

The source documentation describes an installation process based on cloning the platform repository and running an interactive installation script:

git clone https://github.com/indie-engine/indie-engine.git

cd indie-engine

./install.sh

During installation, administrators configure system authentication, execution mode, domain and SSL settings, email configuration, database exposure, and generated credentials.

The platform also uses Let’s Encrypt for SSL certificate provisioning when the appropriate DNS configuration is in place.

This approach reduces the number of manual infrastructure steps required to establish an evaluation or production environment.

Security Through Container Isolation

Enterprise application infrastructure needs more than authentication. It also needs clear boundaries around privileged operations.

Indi Engine AI separates public-facing web execution from host-level administrative functions.

The Apache container does not have direct visibility into sensitive host credentials such as GitHub API tokens used for off-site backup operations.

Instead, when an administrative action is initiated from the web interface, the PHP application communicates with the Wrapper container through an internal HTTPS request.

The Wrapper container validates the request and executes the required host-level operation outside the web server’s process space.

The architecture therefore establishes a simple principle:

The application can request privileged operations without directly possessing the credentials or filesystem access required to execute them.

This container boundary is particularly relevant for self-hosted enterprise environments where infrastructure access needs to remain tightly controlled.

Deterministic Database Schema Ingestion

Generating an application from an existing database depends on one thing above all else: accurately understanding the database.

The ingestion pipeline extracts:

• Tables
• Columns
• Primary keys
• Foreign keys
• Data types
• Database roles
• Existing permissions
• Entity relationships

The extracted information is then stored in a structured JSON metadata representation.

The process can be summarized as:

Database → Credential Authentication → Structure Scanning → Metadata Snapshot → Ext JS Application Design

The platform performs this process using native database connectivity rather than requiring an external AI model to interpret the schema.

That distinction becomes important when considering the role of AI in application generation.

Why Deterministic Processing Matters

There is a tendency to assume that more AI automatically means more automation.

For database application generation, that assumption is not always valid.

Indi Engine AI deliberately avoids using an LLM for the core schema-reflection process.

The reason is architectural rather than philosophical.

The source material notes that an LLM may provide limited value when interpreting a database schema – for example, converting technical field names into more human-readable labels. But obtaining the complete database context required by the model can introduce substantial overhead.

In the SQL Server environment described by the platform architecture, schema reflection can require broad database-dump operations rather than isolated table retrieval. That can translate into significant network traffic and multiple database queries when working against remote infrastructure.

The platform therefore uses deterministic parsing for schema reflection and reserves automation elsewhere in the application lifecycle.

The principle is important:

Use AI where inference creates meaningful value. Use deterministic systems where correctness, performance, and repeatability matter more.

For enterprise architects, this is a useful distinction.

AI does not need to sit in every layer of an application architecture to make a platform automated.

Database Logic Remains Where It Belongs

One of the most important considerations when modernizing an existing database is what happens to the business logic already embedded within it.

Indi Engine AI is designed to preserve server-side database logic, including:

• Triggers
• Stored procedures
• Check constraints
• Custom SQL functions

These remain within the target database and continue to execute natively.

The application layer then reflects resulting data changes through its synchronization architecture.

This separation allows the modernization effort to focus on the application experience without requiring existing database logic to be rewritten as part of the initial application-generation process.

Turning Generated Interfaces into Business-Ready Applications

Automatic application generation solves the first problem: creating the interface.

It does not eliminate the second problem: making that interface usable.

Enterprise applications often contain large datasets, complex relationships, nested records, multiple business states, and highly specific workflows.

Indi Engine AI provides zero-code controls for refining generated Ext JS interfaces.

These include:

• Multi-level column headers
• Locked columns
• Grouped column sets
• Conditional renderers
• Grid chunks
• Form fieldsets
• Foreign-key navigation
• Context-aware dropdown filtering
• Cross-table columns
• Dynamic counters
• Data summaries
• Custom field formatting

These capabilities allow teams to move beyond a generic database grid and create interfaces that reflect how users actually work with the underlying information.

Reduce Complexity at the UI Layer

Enterprise databases frequently expose more information than a user needs at one time.

A database might contain hundreds of possible values for a particular field, even though only a small subset is relevant to the current context.

Indi Engine AI supports contextual filtering that can reduce large dropdown datasets to the values that are actually relevant.

In the benchmark example described in the source material, a country selection containing more than 100 possible choices was reduced to three active countries through contextual filtering.

The broader design principle is straightforward:

The database can remain comprehensive while the user interface remains focused.

Advanced Ext JS Data Presentation

Ext JS provides the component foundation, while Indi Engine AI adds configuration capabilities on top of generated applications.

Examples include row expanders, value templating, cross-table columns, real-time summaries, and dynamic menu counters.

A student grid, for example, can combine a student’s name and age into a single display value while suppressing unnecessary formatting when the age is unavailable.

Related database fields can also be displayed directly within a primary grid. Cross-table values can be visually differentiated to indicate that they originate from related records.

These patterns are particularly relevant to operational applications where users spend significant time reviewing and manipulating structured data.

The objective is not simply to display database records.

It is to make complex relational data usable within a coherent application experience.

Real-Time Enterprise Applications Without Full Page Refreshes

A modern enterprise application cannot always depend on users refreshing the browser to discover whether something changed.

When multiple users, external systems, database procedures, and background processes interact with the same data, application state needs to remain synchronized.

Indi Engine AI addresses this through a combination of:

Change Data Capture + Session State Tracking + WebSockets + Targeted Ext JS Component Updates

The platform maintains state information including:

• Open browser tabs
• Active application views
• Open detail windows
• Applied filters
• Sorting parameters
• Pagination state
• Visible fields
• Currently rendered record IDs

When a database change occurs, the system can identify which application components are affected and push the update to the relevant browser sessions.

From Database Change to UI Update

The process follows four primary stages:

1. The database generates a change event.
2. The CDC pipeline captures the change.
3. The engine maps the affected record to active application state.
4. A WebSocket event updates the relevant Ext JS component.

Instead of invalidating an entire page or forcing a full grid reload, the platform can update specific fields, grid values, or dynamic counters.

That architecture is particularly useful for operational applications where information can change while a user is actively working with the interface.

Handling Database Evolution Without Starting Over

Enterprise databases rarely remain static.

Tables change. Columns are added. Fields are renamed. New relationships are introduced.

A generated application therefore needs a mechanism for handling schema evolution.

Indi Engine AI uses its saved JSON metadata snapshot as a reference point.

When a project reconnects to a modified database, the platform can compare the current database structure against the stored metadata and identify differences.

The resulting workflow allows developers to map newly introduced database attributes into the existing Ext JS application design.

This creates an important modernization advantage:

The application can evolve with the database instead of requiring a complete regeneration whenever the schema changes.

Automated Maintenance Instead of Manual Server Administration

Modernization does not end when an application is deployed.

Self-hosted enterprise platforms also require regular updates, migrations, container rebuilds, and service restarts.

Indi Engine AI packages these activities into a web-based maintenance workflow.

The documented process can:

1. Check dependency versions.
2. Compare the local repository against the remote GitHub repository.
3. Pull updated application code.
4. Execute database migrations.
5. Rebuild Docker images when required.
6. Restart affected containers.

The goal is to replace repetitive SSH-based maintenance procedures with a controlled administrative workflow.

For small engineering teams and organizations operating self-hosted applications, reducing routine infrastructure work can have a direct impact on operational overhead.

Backup Architecture Using GitHub Releases

Backup strategy is another important consideration for self-hosted enterprise applications.

Indi Engine AI uses GitHub Releases as an off-site backup repository, splitting encrypted backup archives into multiple assets to operate within the documented per-file and per-release limits.

The architecture described in the source supports up to 1,000 assets per release, with individual files up to 2 GB, producing approximately 1.9 TB of storage capacity per release under those limits.

The platform also defines a rolling snapshot model:

• Hourly: 0 retained snapshots
• Daily: 7 retained snapshots
• Weekly: 5 retained snapshots
• Monthly: 12 retained snapshots
• Manual: On-demand backups

The architectural objective is straightforward: provide an automated off-site backup mechanism without requiring a separate backup-storage infrastructure layer.

Portability Across Application Environments

Another consequence of the metadata-driven approach is application-design portability.

Because application configurations are stored as self-contained metadata projects, designs can be exported and imported between Indi Engine AI deployments.

The platform is also expanding capabilities for cross-database migration.

However, database portability is not simply a matter of changing connection strings.

Different database engines represent data types differently.

For example, SQL Server’s datetime2 supports up to seven fractional seconds of precision, while PostgreSQL’s timestamp supports up to six.

Moving between those representations therefore introduces a precision difference that needs to be handled explicitly.

Indi Engine AI’s metadata translation layer is designed to intercept these differences and normalize temporal values during cross-engine transformation.

This illustrates a broader principle of database modernization:

Portability requires semantic translation, not just infrastructure abstraction.

What This Means for Legacy Ext JS Modernization

For organizations with aging Ext JS applications, the modernization problem is often more complicated than replacing a visual theme.

Existing applications may contain:

• Legacy user-entry forms
• Complex database relationships
• Established SQL procedures
• Operational workflows
• Large data grids
• Multi-window application patterns
• Existing permissions
• Business-specific interface behavior

Rebuilding all of those capabilities manually can become a significant modernization project.

Indi Engine AI provides another potential path: retain the underlying database infrastructure while generating a modern Ext JS application layer around it.

The platform’s founder-led pilot model is intended to support organizations evaluating this approach for legacy web front ends, database-driven applications, and multi-window operational systems.

The Larger Architectural Lesson

The most interesting aspect of Indi Engine AI is not any single feature.

It is the architectural decision to treat the database schema as an application-generation input.

That changes the modernization workflow from:

Database → Custom APIs → Manual UI Development → State Management → Deployment

to:

Database → Metadata Extraction → Generated Ext JS Application → Configuration → Real-Time Synchronization → Deployment

The distinction matters because enterprise modernization is fundamentally a problem of reducing unnecessary reconstruction.

If the database already contains the entities, relationships, constraints, permissions, and business logic an application needs, rebuilding those structures manually can create significant duplication.

A metadata-driven approach attempts to make the existing infrastructure more valuable by turning it into the foundation for the application experience.

Conclusion: A More Pragmatic Path to Enterprise Application Modernization

Enterprise modernization does not necessarily require abandoning the systems that already run the business.

The more pragmatic question is:

How much of the existing infrastructure can be preserved while significantly improving the application experience?

Indi Engine AI approaches that question through a combination of deterministic schema reflection, Ext JS application generation, zero-code interface configuration, real-time synchronization, containerized deployment, automated maintenance, and metadata-driven portability.

Its architecture also demonstrates an important principle for modern enterprise engineering: automation should not mean introducing AI into every stage of the stack.

Where inference provides value, AI can be useful. Where correctness, performance, and repeatability are the priority, deterministic systems can be the better architectural choice.

For organizations working with legacy SQL databases and Ext JS applications, this creates a practical modernization model:

Preserve the database. Automate the application layer. Modernize the user experience. Keep operational logic where it already works.

That is the core proposition behind generating live Ext JS database applications with Indi Engine AI.