NestJS CRUD Config 🚀
Database-backed configuration management for NestJS applications with full CRUD capabilities
## 📚 Table of Contents
- [Description](#-description)
- [Features](#-features)
- [Installation](#-installation)
- [Migrating to 4.0](#migrating-to-40)
- [Usage](#-usage)
- [Migration System](#-migration-system)
- [API Documentation](#-api-documentation)
- [Database Schema](#-database-schema)
- [Advanced Configuration](#-advanced-configuration)
- [Roadmap](#-roadmap)
- [FAQ](#-faq)
- [License](#-license)
## 📖 Description
NestJS CRUD Config is a powerful configuration management module that revolutionizes how NestJS applications handle configuration data. Unlike traditional environment variable approaches, this library stores configuration in a database with full CRUD operations, making it perfect for dynamic configuration management across multiple environments and services.
The module provides hierarchical organization through sections and data entries, supports optional AES-256-GCM encryption for sensitive values, and includes automatic REST API endpoints for configuration management. Built with TypeScript-first design and leveraging the NestJS CRUD Automator for automatic API generation, it features dynamic entity creation at runtime, named transaction ownership, and intelligent caching.
Whether you're managing API keys across different environments, storing feature flags, or maintaining application settings that need to change without redeployment, this module provides a robust, secure, and scalable solution for microservice architectures, multi-tenant applications, and any system requiring centralized, database-backed configuration management with real-time updates.
## 🚀 Features
- **🗄️ Database-backed configuration storage** - Store configuration in any TypeORM-supported database for persistence and scalability
- **🏗️ Dynamic entity creation** - Entities are created at runtime with customizable table names, field lengths, and constraints
- **📊 Hierarchical organization** - Organize configuration using sections and data entries for better structure and management
- **🔐 AES-256-GCM encryption support** - Protect sensitive configuration values with built-in encryption using industry-standard algorithms
- **🌍 Multi-environment support** - Manage configurations across development, staging, and production environments seamlessly
- **⚡ Full CRUD operations** - Complete Create, Read, Update, Delete operations with automatic REST API endpoints
- **📚 Automatic Swagger documentation** - Generated OpenAPI documentation for all configuration endpoints
- **🎯 TypeScript-first design** - Full type safety with comprehensive interfaces and type definitions
- **🚀 NestJS CRUD Automator integration** - Leverages advanced CRUD automation for controllers and services
- **💾 Intelligent caching** - Built-in caching support with configurable TTL and cache size limits
- **🔄 Named transaction ownership** - Each Automator-owned unit of work uses one exact TypeORM manager, including joined migration writes
- **🎛️ Highly customizable** - Configure table prefixes, field lengths, validation rules, and entity relationships
- **🚦 Flexible controller configuration** - Customize API paths, disable endpoints, or run in headless mode
- **🔧 Advanced CRUD customization** - Full control over routes, swagger documentation, and controller behavior
- **📦 Modular architecture** - Enable/disable features as needed for your use case
- **🚀 Production-ready migration system** - Initialize and manage configuration state during application startup
## 🛠 Installation
These docs describe the CrudConfig 4 contract. Use the 4.x-only range so the package manager cannot resolve an incompatible 3.x release:
```bash
# npm
npm install @elsikora/nestjs-crud-config@^4.0.0-0
# yarn
yarn add @elsikora/nestjs-crud-config@^4.0.0-0
# pnpm
pnpm add @elsikora/nestjs-crud-config@^4.0.0-0
```
### Prerequisites
Install the required peer dependencies:
```bash
npm install @elsikora/nestjs-crud-automator@^4.0.0-0 @nestjs/common@^11.1.24 @nestjs/core@^11.1.24 @nestjs/typeorm@^11.0.0 typeorm@^0.3.20
npm install @nestjs/passport@^11.0.5 @nestjs/platform-fastify@11.1.24 @nestjs/swagger@11.4.2 @nestjs/throttler@^6.5.0 class-transformer@^0.5.1 class-validator@^0.15.1 fastify@^5.8.5 lodash@^4.18.1
```
### Automator 4 compatibility
CrudConfig 4 requires `@elsikora/nestjs-crud-automator >=4.0.0-0 <5.0.0`. Automator 3 is not supported.
Generated route overrides continue to use Automator generation config:
```typescript
DELETE: {
generation: {
isEnabled: false,
},
},
```
ConfigData `CREATE` and `UPDATE` use Automator nested request relation loading. The built-in section relation expects request bodies such as `{ "section": { "id": "section-uuid" } }`.
CrudConfig creates each generated service through `createDynamicService()` and `@ApiService({ entity })`, so its inherited same-entity CRUD methods satisfy the Automator 4 generated-route capability boundary. Applications do not need a wrapper or compatibility layer.
The tested Swagger baseline remains exact `11.4.2`. See [Migrating to 4.0](#migrating-to-40) for the compatibility change.
### Migrating to 4.0
CrudConfig 4 removes Automator 3 compatibility. The CrudConfig runtime contract is otherwise unchanged:
- generated routes keep the same paths, payloads, and `generation.isEnabled` options;
- ConfigData relation input remains `{ "section": { "id": "section-uuid" } }`;
- transaction ownership and `eventManager` join behavior remain unchanged;
- the database schema, duplicate mapping, and EventEmitter-free runtime remain unchanged;
- no consumer wrapper or legacy compatibility wiring is introduced.
See the complete [4.0 migration guide](docs/guides/migrating-to-4-0/page.mdx). The [3.0 migration guide](docs/guides/migrating-to-3-0/page.mdx) remains available for applications upgrading from CrudConfig 2.
### Database Support
This package works with any database supported by TypeORM:
- PostgreSQL
- MySQL/MariaDB
- SQLite
- Microsoft SQL Server
- Oracle
- MongoDB
- CockroachDB
## 💡 Usage
### Basic Setup
```typescript
// app.module.ts
import { Module } from "@nestjs/common";
import { TypeOrmModule } from "@nestjs/typeorm";
import { CrudConfigModule, TOKEN_CONSTANT } from "@elsikora/nestjs-crud-config";
@Module({
imports: [
// First register CrudConfigModule to create dynamic entities
CrudConfigModule.register({
environment: "development",
shouldAutoCreateSections: true,
// Cache configuration
cacheOptions: {
isEnabled: true,
maxCacheItems: 1000,
maxCacheTTL: 3600000, // 1 hour in milliseconds
},
// Encryption configuration
encryptionOptions: {
isEnabled: true,
encryptionKey: process.env.CONFIG_ENCRYPTION_KEY, // 32+ character key
},
// Controller configuration (optional)
controllersOptions: {
section: {
isEnabled: true,
properties: {
path: "api/config/sections",
},
},
data: {
isEnabled: true,
properties: {
path: "api/config/data",
},
},
},
// Entity customization
entityOptions: {
tablePrefix: "app_",
timestampColumnType: "timestamptz", // PostgreSQL; defaults to "timestamp"
configSection: {
tableName: "config_sections",
maxNameLength: 128,
maxDescriptionLength: 512,
},
configData: {
tableName: "config_data",
maxValueLength: 8192,
maxEnvironmentLength: 64,
maxNameLength: 128,
maxDescriptionLength: 512,
},
},
}),
// Then register TypeORM with dynamic entities using registerAsync
TypeOrmModule.forRootAsync({
imports: [CrudConfigModule],
inject: [TOKEN_CONSTANT.CONFIG_SECTION_ENTITY, TOKEN_CONSTANT.CONFIG_DATA_ENTITY],
useFactory: async (sectionEntity, dataEntity) => ({
type: "postgres",
host: "localhost",
port: 5432,
username: "postgres",
password: "postgres",
database: "config_db",
entities: [
// Your other entities
// UserEntity, ProductEntity, etc.
// Dynamic entities from CrudConfigModule
sectionEntity,
dataEntity,
],
synchronize: true,
}),
}),
],
})
export class AppModule {}
```
### Using the Configuration Service
```typescript
// config.service.ts
import { Injectable } from "@nestjs/common";
import { CrudConfigService } from "@elsikora/nestjs-crud-config";
@Injectable()
export class MyConfigService {
constructor(private readonly configService: CrudConfigService) {}
async setupApplicationConfig() {
// Set a configuration value
await this.configService.set({
section: "api-settings",
name: "API_KEY",
value: "my-secret-api-key",
description: "Production API key",
environment: "production",
});
// Retrieve configuration by section and name
const apiConfig = await this.configService.get({
section: "api-settings",
name: "API_KEY",
environment: "production",
shouldLoadSectionInfo: true,
useCache: true,
});
console.log("API Configuration:", apiConfig);
// apiConfig.value will be automatically decrypted if it was encrypted
return apiConfig;
}
async getConfigurationList() {
// Get all configurations in a section
const configs = await this.configService.getList({
section: "api-settings",
environment: "production",
useCache: true,
});
return configs;
}
async deleteConfiguration() {
// Delete a configuration
await this.configService.delete({
section: "api-settings",
name: "API_KEY",
environment: "production",
});
}
}
```
### Async Module Registration
When using `registerAsync()`, static options like controllers and entity configuration must be provided via the `staticOptions` property, as NestJS does not support async controller registration:
```typescript
// app.module.ts
import { Module } from "@nestjs/common";
import { ConfigModule, ConfigService } from "@nestjs/config";
import { CrudConfigModule } from "@elsikora/nestjs-crud-config";
@Module({
imports: [
ConfigModule.forRoot(),
CrudConfigModule.registerAsync({
imports: [ConfigModule],
inject: [ConfigService],
// Dynamic options - resolved asynchronously
useFactory: async (configService: ConfigService) => ({
environment: configService.get("NODE_ENV", "development"),
encryptionOptions: {
isEnabled: true,
encryptionKey: configService.get("ENCRYPTION_KEY"),
},
cacheOptions: {
isEnabled: true,
maxCacheItems: 1000,
maxCacheTTL: 3600000,
},
}),
// Static options - must be known at module registration time
staticOptions: {
controllersOptions: {
section: {
isEnabled: true,
properties: {
path: "api/config/sections",
},
},
data: {
isEnabled: true,
properties: {
path: "api/config/data",
},
},
},
entityOptions: {
tablePrefix: "app_",
timestampColumnType: "timestamptz", // Must be static for dynamic entities
configSection: {
tableName: "config_sections",
maxNameLength: 128,
},
configData: {
tableName: "config_data",
maxValueLength: 8192,
},
},
migrationEntityOptions: {
tableName: "config_migrations",
},
},
}),
],
})
export class AppModule {}
```
**Important:** The `staticOptions` property contains configuration that must be known at module compilation time:
- `controllersOptions` - REST API controller configuration
- `entityOptions` - Database entity customization (table names, field lengths, timestamp type)
- `migrationEntityOptions` - Migration tracking table configuration
## 🚀 Migration System
The NestJS CRUD Config module includes a powerful **production-ready migration system** that allows you to initialize and manage configuration state during application startup. This system ensures your application always has the required configuration data across different environments and deployments.
### Key Features
- **🔄 Automatic execution on startup** - Migrations run automatically when the application bootstraps
- **💾 Named transaction support** - Transaction-enabled migrations run inside one named Automator owner
- **🌍 Environment-specific configurations** - Create different configurations for different environments
- **📊 Migration tracking** - Complete audit trail with timestamps and execution status
- **🔙 Rollback support** - Define rollback procedures for each migration
- **⚡ Stuck migration cleanup** - Automatic timeout and cleanup of crashed migrations
- **🎯 Type-safe status tracking** - Uses `EConfigMigrationStatus` enum for reliable status management
- **🛡️ Race condition protection** - Thread-safe execution preventing concurrent conflicts
### Migration Status Enum
The migration system uses the `EConfigMigrationStatus` enum to track migration states:
```typescript
import { EConfigMigrationStatus } from "@elsikora/nestjs-crud-config";
// Available statuses:
EConfigMigrationStatus.PENDING; // Migration is pending execution
EConfigMigrationStatus.RUNNING; // Migration is currently running
EConfigMigrationStatus.COMPLETED; // Migration completed successfully
EConfigMigrationStatus.FAILED; // Migration failed with error
EConfigMigrationStatus.STUCK; // Migration is stuck (timeout)
```
### Basic Migration Configuration
Configure migrations in your module registration:
```typescript
import { CrudConfigModule } from "@elsikora/nestjs-crud-config";
import { initialAppConfigMigration } from "./migrations/001-initial-app-config.migration";
@Module({
imports: [
CrudConfigModule.register({
environment: process.env.NODE_ENV || "development",
// Migration configuration
migrationOptions: {
isEnabled: true,
shouldRunOnStartup: true,
useTransaction: true,
stuckMigrationTimeoutMinutes: 30,
tableName: "config_migrations", // Optional: custom table name
migrations: [
initialAppConfigMigration,
// Add more migrations here
],
},
// Other configuration options...
}),
],
})
export class AppModule {}
```
With `useTransaction: true` (the default), execution owns one `crud-config-migrations` transaction and passes its exact `EntityManager` to each migration callback. Pass that manager as `eventManager` to every config operation in the migration. Omitting it from `set()` would attempt to open the separate `crud-config-set` owner, and Automator rejects nested owners.
With `useTransaction: false`, there is no migration-wide owner and callbacks receive `undefined`. A standalone `set()` still owns its own atomic `crud-config-set` transaction, so several config writes are not one all-or-nothing unit. Rollback execution always uses the named migration owner.
### Creating Migration Files
Create a migration file with the required structure:
```typescript
// migrations/001-initial-app-config.migration.ts
import type { IConfigMigrationDefinition } from "@elsikora/nestjs-crud-config";
import type { CrudConfigService } from "@elsikora/nestjs-crud-config";
import type { EntityManager } from "typeorm";
export const initialAppConfigMigration: IConfigMigrationDefinition = {
name: "001_initial_app_config",
description: "Initialize basic application configuration",
async up(configService: CrudConfigService, entityManager?: EntityManager): Promise {
// Create application settings
await configService.set({
section: "app-settings",
name: "APP_NAME",
value: "My Application",
description: "Application name",
environment: "default",
eventManager: entityManager,
});
await configService.set({
section: "app-settings",
name: "APP_VERSION",
value: "1.0.0",
description: "Application version",
environment: "default",
eventManager: entityManager,
});
// Create API settings
await configService.set({
section: "api-settings",
name: "API_RATE_LIMIT",
value: "100",
description: "API rate limit per minute",
environment: "default",
eventManager: entityManager,
});
},
async down(configService: CrudConfigService, entityManager?: EntityManager): Promise {
// Rollback: remove configurations created by this migration
const configurationsToRemove = [
{ name: "APP_NAME", section: "app-settings" },
{ name: "APP_VERSION", section: "app-settings" },
{ name: "API_RATE_LIMIT", section: "api-settings" },
];
for (const config of configurationsToRemove) {
try {
await configService.delete({
section: config.section,
name: config.name,
environment: "default",
eventManager: entityManager,
});
} catch (error) {
// Expected if config was never created
console.warn(`Failed to delete config ${config.section}:${config.name} during rollback`);
}
}
},
};
```
### Environment-Specific Migrations
Create migrations that work with different environments:
```typescript
// migrations/002-environment-specific-config.migration.ts
export const environmentSpecificConfigMigration: IConfigMigrationDefinition = {
name: "002_environment_specific_config",
description: "Environment-specific configuration settings",
async up(configService: CrudConfigService, entityManager?: EntityManager): Promise {
const environments = ["development", "staging", "production"];
for (const env of environments) {
// Environment-specific debug settings
await configService.set({
section: "app-settings",
name: "DEBUG_MODE",
value: env === "development" ? "true" : "false",
description: "Enable debug mode",
environment: env,
eventManager: entityManager,
});
// Environment-specific API limits
const rateLimits = {
development: "1000",
staging: "500",
production: "100",
};
await configService.set({
section: "api-settings",
name: "API_RATE_LIMIT",
value: rateLimits[env],
description: "API rate limit per minute",
environment: env,
eventManager: entityManager,
});
}
},
async down(configService: CrudConfigService, entityManager?: EntityManager): Promise {
const environments = ["development", "staging", "production"];
const configurationsToRemove = [
{ name: "DEBUG_MODE", section: "app-settings" },
{ name: "API_RATE_LIMIT", section: "api-settings" },
];
for (const config of configurationsToRemove) {
for (const environment of environments) {
try {
await configService.delete({
section: config.section,
name: config.name,
environment: environment,
eventManager: entityManager,
});
} catch (error) {
console.warn(
`Failed to delete config ${config.section}:${config.name}:${environment} during rollback`,
);
}
}
}
},
};
```
### Advanced Migration Configuration
Configure migrations with custom options:
```typescript
CrudConfigModule.registerAsync({
imports: [ConfigModule],
inject: [ConfigService],
useFactory: async (configService: ConfigService) => ({
environment: configService.get("NODE_ENV", "development"),
migrationOptions: {
isEnabled: true,
shouldRunOnStartup: true,
useTransaction: true,
stuckMigrationTimeoutMinutes: 60, // Custom timeout
migrations: [
initialAppConfigMigration,
environmentSpecificConfigMigration,
// Add more migrations in order
],
},
// Other dynamic options...
}),
// Static options for entities and controllers
staticOptions: {
migrationEntityOptions: {
tableName: "my_migrations", // Custom table name must be in staticOptions
maxNameLength: 256,
},
controllersOptions: {
section: { isEnabled: true },
data: { isEnabled: true },
},
},
});
```
### Migration Best Practices
1. **Naming Convention**: Use descriptive names with sequence numbers
- ✅ `001_initial_app_config`
- ✅ `002_add_feature_flags`
- ❌ `migration1`, `config_setup`
2. **Retry safety**: Use `set()` as the upsert for a configuration key
```typescript
await configService.set({ eventManager: entityManager, ...properties });
```
3. **Error Handling**: Always handle errors gracefully
```typescript
try {
await configService.set({ eventManager: entityManager, ...properties });
} catch (error) {
console.error("Migration failed:", error);
throw error; // Re-throw to mark migration as failed
}
```
4. **Rollback Support**: Always implement the `down` method
```typescript
async down(configService: CrudConfigService, entityManager?: EntityManager): Promise {
// Implement rollback logic
}
```
5. **Environment Awareness**: Use environment-specific configurations
```typescript
const currentEnv = process.env.NODE_ENV || "development";
await configService.set({
eventManager: entityManager,
environment: currentEnv,
// ... other options
});
```
### Migration Monitoring
Monitor migration execution with logging:
```typescript
import { EConfigMigrationStatus } from "@elsikora/nestjs-crud-config";
@Injectable()
export class MigrationMonitorService {
constructor(private readonly migrationService: ConfigMigrationService) {}
async getMigrationStatus(): Promise {
const migrations = await this.migrationService.getExecutedMigrations();
const completed = migrations.filter((m) => m.status === EConfigMigrationStatus.COMPLETED);
const failed = migrations.filter((m) => m.status === EConfigMigrationStatus.FAILED);
const stuck = migrations.filter((m) => m.status === EConfigMigrationStatus.STUCK);
console.log(
`Migrations - Completed: ${completed.length}, Failed: ${failed.length}, Stuck: ${stuck.length}`,
);
}
async getFailedMigrations(): Promise {
const migrations = await this.migrationService.getExecutedMigrations();
return migrations.filter((m) => m.status === EConfigMigrationStatus.FAILED);
}
}
```
### Testing Migrations
Test your migrations in different environments:
```typescript
describe("Initial App Config Migration", () => {
let configService: CrudConfigService;
let migration: IConfigMigrationDefinition;
beforeEach(async () => {
// Setup test environment
migration = initialAppConfigMigration;
});
it("should create required configurations", async () => {
await migration.up(configService);
const appName = await configService.get({
section: "app-settings",
name: "APP_NAME",
environment: "default",
});
expect(appName.value).toBe("My Application");
});
it("should rollback configurations", async () => {
await migration.up(configService);
await migration.down(configService);
await expect(
configService.get({
section: "app-settings",
name: "APP_NAME",
environment: "default",
}),
).rejects.toThrow();
});
});
```
## 📚 API Documentation
The module automatically generates REST API endpoints with customizable paths:
### Configuration Sections (default: `/config/section`)
- `GET /config/section` - List all sections
- `POST /config/section` - Create a new section
- `GET /config/section/:id` - Get section by ID
- `PUT /config/section/:id` - Update section
- `DELETE /config/section/:id` - Delete section
**Request Body for POST/PUT:**
```json
{
"name": "api-settings",
"description": "API configuration settings"
}
```
### Configuration Data (default: `/config/data`)
- `GET /config/data` - List all configuration data
- `POST /config/data` - Create new configuration
- `GET /config/data/:id` - Get configuration by ID
- `PUT /config/data/:id` - Update configuration
- `DELETE /config/data/:id` - Delete configuration
**Request Body for POST/PUT:**
```json
{
"name": "API_KEY",
"value": "your-secret-key",
"environment": "production",
"description": "Production API key",
"isEncrypted": true,
"section": { "id": "section-uuid-here" }
}
```
### Customizing API Endpoints
```typescript
CrudConfigModule.register({
controllersOptions: {
section: {
properties: {
path: "api/v1/settings/sections",
name: "CustomSectionController",
swagger: {
tags: ["Configuration Sections"],
},
},
},
data: {
properties: {
path: "api/v1/settings/data",
routes: {
DELETE: { generation: { isEnabled: false } }, // Disable deletion
},
},
},
},
});
```
Automator 4 route options use `generation.isEnabled` for route generation. Relation loading uses TypeORM `relationLoadStrategy` values (`"query"` or `"join"`); the built-in ConfigData section relation uses `"query"`.
## 🗄️ Database Schema
The module creates two main tables with the following default structure:
### Configuration Sections Table (`config_section`)
```sql
CREATE TABLE config_section (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
name VARCHAR(128) NOT NULL UNIQUE,
description VARCHAR(512),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
```
### Configuration Data Table (`config_data`)
```sql
CREATE TABLE config_data (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
name VARCHAR(128) NOT NULL,
value VARCHAR(8192) NOT NULL,
environment VARCHAR(64) NOT NULL,
description VARCHAR(512),
is_encrypted BOOLEAN DEFAULT FALSE,
section_id UUID NOT NULL REFERENCES config_section(id) ON DELETE CASCADE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
UNIQUE(name, environment, section_id)
);
```
## 🔧 Advanced Configuration
### Encryption Support
The module provides built-in AES-256-GCM encryption for sensitive configuration values:
```typescript
// Enable encryption with bounded derived-key reuse for repeated uncached reads
CrudConfigModule.register({
cacheOptions: { isEnabled: false },
encryptionOptions: {
isEnabled: true,
encryptionKey: process.env.CONFIG_ENCRYPTION_KEY, // 32+ character key
derivedKeyCacheMaxEntries: 64,
},
});
// When encryption is enabled, all values are encrypted automatically
await configService.set({
section: "database",
name: "DB_PASSWORD",
value: "my-secret-password",
});
// Retrieve and decrypt automatically
const config = await configService.get({
section: "database",
name: "DB_PASSWORD",
useCache: false,
});
console.log(config.value); // Automatically decrypted value
console.log(config.isEncrypted); // true
```
`encryptionOptions.derivedKeyCacheMaxEntries` bounds the number of derived keys retained by each module instance using `lru-cache`. Omit it or set it to `0` to disable reuse; a positive safe integer enables it. The same option is available through `registerAsync()`.
This cache retains derived encryption keys in process memory, not configuration values. With `useCache: false`, each read still fetches the current database value, and every decrypt call authenticates the supplied ciphertext with AES-GCM. Only successful decryption populates or promotes a cache entry. Eviction, module destruction, or successful decryption with a different encryption key clears the affected key buffers. Encrypted storage format and the synchronous encryption API are unchanged.
### Transaction and Duplicate Protection
`CrudConfigService.set()` owns a named Automator transaction when called without `eventManager`. When a migration supplies its owner manager, all generated ConfigSection and ConfigData service operations join that same transaction.
The package does not require consumer `EventEmitterModule` wiring. ConfigData uniqueness is enforced by the database across `name`, `environment`, and `section`; Automator maps a conflicting generated create or update to `409 CONFIGDATA_DUPLICATE_KEY`. Put application-specific validation or auditing in the application service/lifecycle layer rather than a package before-insert event.
### Headless Mode (Without Controllers)
```typescript
CrudConfigModule.register({
controllersOptions: {
section: { isEnabled: false },
data: { isEnabled: false },
},
});
```
This is perfect for:
- Background services that only need programmatic access
- Microservices that manage config through message queues
- Applications with custom GraphQL or gRPC interfaces
### Working with Multiple Environments
```typescript
// multi-env.service.ts
@Injectable()
export class MultiEnvironmentService {
constructor(private readonly configService: CrudConfigService) {}
async setupEnvironmentConfigs() {
const environments = ["development", "staging", "production"];
for (const env of environments) {
await this.configService.set({
section: "database",
name: "DATABASE_URL",
environment: env,
value: `postgres://localhost:5432/${env}_db`,
description: `Database URL for ${env} environment`,
});
}
}
}
```
## 🛣 Roadmap
| Task / Feature | Status |
| --------------------------------------------- | -------------- |
| Core dynamic entity system | ✅ Done |
| TypeORM integration with all databases | ✅ Done |
| Hierarchical configuration (sections/data) | ✅ Done |
| Full CRUD operations with REST API | ✅ Done |
| Swagger/OpenAPI documentation | ✅ Done |
| Multi-environment support | ✅ Done |
| Named Automator transaction ownership | ✅ Done |
| Caching system with TTL | ✅ Done |
| Custom table names and prefixes | ✅ Done |
| Validation and constraints | ✅ Done |
| NestJS CRUD Automator integration | ✅ Done |
| TypeScript interfaces and types | ✅ Done |
| AES-256-GCM encryption support | ✅ Done |
| Async module registration | ✅ Done |
| Auto-section creation | ✅ Done |
| GraphQL API endpoints | 🚧 In Progress |
| Configuration versioning and history | 🚧 In Progress |
| Role-based access control (RBAC) | 🚧 In Progress |
| Configuration templates and inheritance | 🚧 In Progress |
| Real-time configuration updates via WebSocket | 🚧 In Progress |
| Configuration validation schemas | 🚧 In Progress |
| Bulk import/export functionality | 🚧 In Progress |
| Configuration diff and merge tools | 🚧 In Progress |
| Audit logging and change tracking | 🚧 In Progress |
| Configuration backup and restore | 🚧 In Progress |
| Integration with external secret managers | 🚧 In Progress |
## ❓ FAQ
### What databases are supported?
The module supports any database that TypeORM supports, including:
- **PostgreSQL** - Recommended for production
- **MySQL/MariaDB** - Popular choice for web applications
- **SQLite** - Perfect for development and testing
- **Microsoft SQL Server** - Enterprise database support
- **Oracle** - Enterprise-grade database
- **MongoDB** - NoSQL document database
- **CockroachDB** - Distributed SQL database
### How does this compare to environment variables?
While environment variables are great for simple configurations, this module provides:
- **Database persistence** - Configurations survive container restarts
- **Runtime updates** - Change configurations without redeployment
- **Hierarchical organization** - Group related configurations
- **Multi-environment support** - Manage dev/staging/prod from one place
- **Encryption support** - Secure sensitive data
- **REST API** - Manage configurations programmatically
- **Audit trails** - Track configuration changes
### Can I migrate from environment variables?
Yes! You can easily migrate by programmatically setting configurations during application startup:
```typescript
async function migrateFromEnvVars() {
const configs = [
{ section: "database", name: "DATABASE_URL", value: process.env.DATABASE_URL },
{ section: "api", name: "API_KEY", value: process.env.API_KEY },
// ... more configurations
];
for (const config of configs) {
await configService.set(config);
}
}
```
### How do I handle sensitive configuration data?
The module provides built-in AES-256-GCM encryption support:
```typescript
CrudConfigModule.register({
encryptionOptions: {
isEnabled: true,
encryptionKey: process.env.CONFIG_ENCRYPTION_KEY,
},
});
```
Sensitive values are automatically encrypted before storage and decrypted when retrieved.
### Can I use this with microservices?
Absolutely! The module is perfect for microservice architectures:
- **Centralized configuration** - All services can share the same config database
- **Service-specific sections** - Organize configurations by service
- **Environment isolation** - Separate dev/staging/prod configurations
- **Dynamic updates** - Update configurations without service restarts
### How do I customize table names and field sizes?
The module provides extensive customization options:
```typescript
CrudConfigModule.register({
entityOptions: {
tablePrefix: "myapp_",
timestampColumnType: "timestamptz",
configSection: {
tableName: "configuration_sections",
maxNameLength: 256,
maxDescriptionLength: 1024,
},
configData: {
tableName: "configuration_values",
maxValueLength: 16384, // 16KB values
maxEnvironmentLength: 128,
maxNameLength: 256,
maxDescriptionLength: 1024,
},
},
});
```
`timestampColumnType` applies to all nine temporal columns in the section, data, and migration entities. It defaults to `"timestamp"`; choose a TypeORM `ColumnType` supported by your database driver, such as `"timestamptz"` for PostgreSQL or `"datetime"` for SQL.js/SQLite. Changing it for an existing database still requires the corresponding schema migration.
### What happens if the database is unavailable?
The module includes caching to handle temporary database outages:
- **In-memory cache** - Recently accessed configurations are cached
- **Configurable TTL** - Control how long configurations are cached
- **Graceful degradation** - Falls back to cached values when database is unavailable
### Can I use this without REST API endpoints?
Yes! The module supports "headless mode" where controllers are disabled:
```typescript
CrudConfigModule.register({
controllersOptions: {
section: { isEnabled: false },
data: { isEnabled: false },
},
});
```
### Is this production-ready?
Yes! The module is built with production use in mind:
- **Type-safe** - Full TypeScript support prevents runtime errors
- **Battle-tested** - Built on proven technologies (NestJS, TypeORM)
- **Scalable** - Works with enterprise databases
- **Secure** - Built-in encryption and validation
- **Observable** - Comprehensive logging and monitoring hooks
## 🔒 License
This project is licensed under **MIT License**
Copyright (c) 2025 ElsiKora
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.