Application configuration handbook
Choose the correct runtime setup, inspect every option and verify a complete typed application.
In plain language
Configuration is the application’s startup plan. Choose a service, follow its setup chapter, and verify that its actual startup code consumes the option.
Look up a word · Learn step by stepConfigure by responsibility#
Start with the application's owning process and the feature you need. zerux.config.js/.ts is server startup input. Some packages participate in managed service startup; other packages are explicit factories or browser helpers. A property accepted by an open TypeScript type is not proof of a runtime consumer.
| Responsibility | Configuration chapter | What it establishes |
|---|---|---|
| Config file/export/precedence | zerux.config.js | Which module is loaded and when |
| Paths, modules and environment | Structure | Relative discovery paths and environment timing |
| Listener and hosts | Server | Actual CLI/config precedence and host policy |
| Named databases/adapters | Database | Connection slugs, default manager and ownership |
| Memory/Redis caching | Cache | Adapter, namespace, TTL and required policy |
| Local/S3 object stores | Files | Store drivers, access limits and private roots |
| SMTP, inbound and campaigns | Account setup and independent opt-in features | |
| Internal events and collector | Analytics | Database binding and bounded ingestion |
| Browser/server event destinations | Tags | Consent, shared stores and protected administration |
| Charts/studio | Reports | Authorization, tenant scope and data coverage |
| Durable job processing | Queue | Redis, named producers/workers and retries |
| Lifecycle/thread work | Workers | Pool defaults and task lifetime |
| RPC/MCP and other protocols | Protocols | Registration, authorization and body/origin limits |
| Server/browser appearance helpers | Theme | Mode/cookie/script defaults and compatibility |
| Login/request enforcement | Auth/security | Explicit setup and current automatic-integration limits |
Follow a complete setup sequence#
- Create a minimal ESM application and one working route using installation.
- Add strict checking from the TypeScript guide, even if production output is bundled/transpiled separately.
- Configure paths and allowed hosts. Keep private environment, database and upload paths outside public assets.
- Enable one service and its actual prerequisites. Confirm readiness and perform one real operation before adding a dependent service.
- Test invalid input, missing infrastructure and shutdown. Choose required/degraded behavior intentionally.
- Build the production artifact and repeat the request with the deployment environment and identity.
Do not add every package to a config object to make an application look complete. Configure only the infrastructure actually used, and put explicit helper initialization in the appropriate plugin/worker/component owner.
TypeScript and JavaScript together#
A JavaScript default export can use JSDoc ZeruxConfig; TypeScript can use satisfies ZeruxConfig. Check a nested service against NonNullable<ZeruxConfig['cache']> or the corresponding field because the open root type allows custom keys. Individual chapters show both forms and exact option contracts.
Unknown HTTP bodies, environment strings and persisted snapshots still require runtime validation. A valid callback type does not prove the callback authenticates anyone. A successful build does not establish an SMTP, Redis or database connection.
A small complete application#
Follow complete configuration examples for a local SQLite/memory-cache/files setup and a production-shaped PostgreSQL/Redis configuration. These examples choose a narrow set of services rather than relying on unavailable secrets. Add protected email/analytics/admin integrations only after their identity, storage and failure policies are defined.
Reference and troubleshooting#
The configuration reference lists the declared root/interface shapes, while each service guide explains the actual consumer, values and lifecycle. Use troubleshooting to separate file precedence, module-format, type, environment and infrastructure failures. A root type entry that is not consumed is documented as such instead of being presented as a working switch.