Question 1

What is Enravo?

Accepted Answer

Enravo is a technology company that builds software on its own infrastructure. Enravo Core is a modular platform that covers everything from data management and API generation to identity, device control, and security — all designed and maintained internally. Every product we deliver runs on Core.

Question 2

What is Enravo Core?

Accepted Answer

Enravo Core is a modular, API-first platform with two interconnected layers. The Platform Layer handles data, APIs, modules, and UI — the operational backbone. The Trust Layer handles identity, device management, cryptographic signing, and threat detection — the security backbone. Together, they form a single foundation where security is not optional; it is how the system works.

Question 3

What is Rakton?

Accepted Answer

Rakton is our first product line, built entirely on Enravo Core. It provides multi-branch commerce and delivery operations — order management, polygon-based delivery zones, campaign engine, multi-channel integration, and real-time tracking. Rakton includes Delivery, Commerce, and upcoming ERP and POS modules.

Question 4

Who is Enravo for?

Accepted Answer

Any team or organization building software that requires identity management, device-level security, and API infrastructure they fully control. Enravo Core and Enravo Trust can run standalone — powering SaaS platforms, mobile applications, multi-tenant systems, internal tools, or IoT backends. Rakton is proof of this: a full commerce and delivery platform built entirely on Core. But Core is not limited to commerce — it is a general-purpose infrastructure layer for any software that refuses to compromise on security.

Question 5

What makes Enravo different?

Accepted Answer

Three things. First, we built the security layer before we built any product — security is the architecture, not a feature bolted on later. Second, every product we deliver runs on the same modular platform: Enravo Core and Enravo Trust. This means Core isn't a one-time project — it matures with every deployment, every edge case, and every production workload. The more software we build on it, the more battle-tested the foundation becomes. Third, we don't depend on third-party identity, authentication, or security providers. Every layer — from cryptographic signing to device management to policy evaluation — is engineered and maintained by us.

Question 6

Is Enravo a SaaS product?

Accepted Answer

No. Enravo is not a sign-up-and-use SaaS. Each deployment runs on dedicated infrastructure with its own database, security policies, and module configuration. We offer four engagement models: Solution Delivery, Product Adoption, Partnership, and Core Licensing (coming soon).

Question 7

Is Enravo open source?

Accepted Answer

Enravo Core is not open source. Our architecture documentation and integration guides are publicly available. Core Licensing, which will allow organizations to run Enravo Core on their own infrastructure, is on our roadmap.

Question 8

How do I get in touch?

Accepted Answer

Visit our contact page or email us directly. Whether you have a technical question, a partnership idea, or a project you want to discuss — we respond to every message.

Question 9

What is the Schema Engine?

Accepted Answer

Define your data model as a schema — fields, types, validation rules, and permissions. The Schema Engine automatically generates REST endpoints, CRUD operations, sanitization pipelines, and admin UI schemas from that single definition. You describe what you want; the engine builds the infrastructure.

Question 10

What is the API Engine?

Accepted Answer

Every schema you define becomes a set of auto-generated REST endpoints with standardized response envelopes, guard pipeline integration, and OpenAPI documentation. Custom endpoints are defined through controllers with routesMeta() — one definition serves route registration, ability derivation, and API docs simultaneously.

Question 11

What is the Module System?

Accepted Answer

Modules are self-contained units with their own schemas, migrations, abilities, settings, REST controllers, and lifecycle hooks. Each module registers through a ModuleProvider interface — zero coupling between modules. You can add, remove, or update modules without touching the rest of the system. Enravo Core ships with 13 bundled modules.

Question 12

How does the Meta System work?

Accepted Answer

The Meta System extends standard entities (orders, products, users, sessions) with custom metadata. Each meta field has its own read/write permissions, context visibility (admin, account, cart), and validation rules. You define metadata once; the system controls who can see and edit it based on role and context.

Question 13

What is the UI Engine?

Accepted Answer

The UI Engine generates admin interfaces from schema definitions. View-based definitions, widget libraries, section layouts, and dynamic form rendering — all driven by the same schema that generates your API. Change the schema, and both the API and UI update together.

Question 14

How does access control work?

Accepted Answer

Access control in Enravo is role-based with 40+ granular abilities and wildcard matching. Each ability maps to a security policy that defines auth requirements, PoP mode, rate limits, and attestation levels. Abilities are auto-derived from schemas and controller definitions — no manual wiring. Permissions are evaluated at request time, not at build time.

Question 15

Does Enravo support multiple channels?

Accepted Answer

Yes. The platform is API-first and headless — web, mobile, desktop, and server clients all use the same API with the same security model. Each channel can be a separate Client with its own security policies, device limits, and signing method (ECDSA for mobile, HMAC for web/server).

Question 16

What is Enravo Trust?

Accepted Answer

Enravo Trust is the security layer inside Enravo Core. It is not a plugin or middleware you can bypass — it is the foundation that every request passes through. It covers authentication, device binding, cryptographic proof of possession, app integrity verification, policy-driven access control, threat detection, and audit logging.

Question 17

What is the Guard Pipeline?

Accepted Answer

The Guard Pipeline is a six-stage security verification chain evaluated on every API request: (1) JWT validation — token signature, expiry, and claims, (2) Device resolution — device status and cache verification, (3) PoP verification — ECDSA or HMAC signature validation, (4) App ID chain — ensures the token's device matches the signing device, (5) Rate limiting — per-app, per-user, per-IP throttling, (6) Permission check — role-based ability matching. No stage can be skipped. A request that fails any stage is rejected before reaching business logic.

Question 18

What is Proof of Possession (PoP)?

Accepted Answer

Every mutating request is cryptographically signed with the device's private key. Mobile and desktop clients use ECDSA P-256 — the private key lives in the device's Secure Enclave and never leaves. Web clients use HMAC-SHA256 through a Backend-for-Frontend (BFF) pattern. Even if a token is intercepted, it cannot produce valid signatures without the original device. A stolen token is a useless token.

Question 19

What happens if a token is stolen?

Accepted Answer

Nothing useful. The attacker has a JWT but cannot sign requests — they don't have the device's private key. The Guard Pipeline verifies the PoP signature on every request and rejects anything unsigned or signed with the wrong key. Additionally, the App ID chain check ensures the JWT's bound device matches the signing app — preventing token reuse across devices.

Question 20

What is Device Binding?

Accepted Answer

Each device generates a hardware-anchored ECDSA P-256 key pair during app installation. The public key is registered server-side; the private key never leaves the device hardware. Every session is bound to this device identity. Devices have lifecycle states (active, logged out, revoked, suspended) and can be individually managed without affecting other sessions. Per-client device limits prevent unlimited device registration.

Question 21

What is App Integrity verification?

Accepted Answer

Before trusting a device, the platform verifies that the app itself is genuine and unmodified. Android uses Play Integrity API; iOS uses App Attest. This prevents requests from modified APKs, rooted devices, or emulators. Attestation can be enforced per action (install, login, token refresh) with three modes: enforce (block), soft_fail (warn), or telemetry (log only).

Question 22

How does the Policy Engine work?

Accepted Answer

Each API endpoint is governed by a security policy that defines: authentication type (JWT, HMAC, none), PoP mode (required, optional, disabled), rate limits, attestation requirements, and IP allowlists. Policies are declarative — no hardcoded security rules in application code. You can change a policy without touching a single line of business logic.

Question 23

What is auto-ban and threat detection?

Accepted Answer

The system automatically responds to security violations. Five consecutive signature failures trigger a device block. A single nonce replay attempt triggers an immediate ban. Brute-force login attempts lock the IP for 15 minutes. All thresholds are configurable through the Policy Engine. Every security event is logged in the audit trail with full context.

Question 24

What is a Client in Enravo?

Accepted Answer

A Client represents a platform or environment that connects to Enravo Core — for example, your iOS app, your Android app, your web storefront, or a server-to-server integration. Each Client has its own Client ID, Client Secret, security policies, and device limits. Clients are independently managed: you can revoke one client without affecting others.

Question 25

What is an App in Enravo?

Accepted Answer

An App is a specific installation of a Client on a specific device. When a user installs your mobile app, an App record is created with a unique app_id, the device's public key, and platform information. Apps have lifecycle states: pending, active, revoked, banned. An App is the bridge between a Client definition and a physical device.

Question 26

What is a Device?

Accepted Answer

A Device is the hardware identity — the actual phone, tablet, or computer. It is identified by its cryptographic key pair generated during installation. One device can have one app per client. The device's private key is stored in hardware (Secure Enclave on iOS, Keystore on Android) and is used to sign every request.

Question 27

How do Client, App, and Device relate to each other?

Accepted Answer

Think of it as a hierarchy: Client (your platform) → App (one installation) → Device (the hardware). A Client can have many Apps across many Devices. Each App belongs to exactly one Client and one Device. When a user logs in, a session is created that binds User → App → Device. The Guard Pipeline verifies this entire chain on every request — if any link is broken, the request is rejected.

Question 28

Can a user have multiple devices?

Accepted Answer

Yes. Each device gets its own key pair and its own App record. Per-client device limits control how many devices a user can register (e.g., max 3 devices for mobile client). When the limit is reached, the user must revoke an existing device before adding a new one — or the admin can configure automatic replacement of the oldest device.

Question 29

What happens when a device is revoked?

Accepted Answer

All sessions on that device are immediately invalidated. The device's public key is added to a blacklist cache for instant rejection. Active refresh tokens for that device are deleted. The user's other devices continue working unaffected. The audit log records who revoked the device and when.

Question 30

What is the install flow for a new device?

Accepted Answer

The device requests an install challenge from the server. The server returns a one-time challenge string. The device generates an ECDSA P-256 key pair in hardware and sends back the challenge response, public key, and platform info. The server verifies the challenge, stores the public key, and creates an App record. The challenge includes the public key fingerprint to prevent key substitution attacks.

Question 31

How is request signing implemented?

Accepted Answer

The signature base string follows a structured format: HTTP method, path, content digest (SHA-256), timestamp, nonce, and app_id. The client signs this with its private key (ECDSA) or shared secret (HMAC). The server reconstructs the same base string and verifies. Timestamp window is ±60 seconds in production. Every nonce is tracked to prevent replay attacks.

Question 32

What database tables does Enravo Core use?

Accepted Answer

19 core tables covering: API clients, client apps, device installs, refresh tokens, request nonces, 2FA sessions, rate limits, banned apps, audit logs, security alerts, security change logs, roles, user roles, abilities, role-ability mappings, policies, addresses, and license keys. Module-specific tables are created dynamically during module registration.

Question 33

How does caching work?

Accepted Answer

Two-tier cache: L1 (object cache, per-request) and L2 (transients, persistent with TTL). Device resolution uses a three-tier strategy: request memoization, object cache with 2-minute TTL, and transient fallback. Ability sync uses hash-based change detection — typically 0-2 database queries instead of approximately 60 on each request. Cache invalidation is hook-driven and automatic.

Question 34

Does Enravo generate API documentation automatically?

Accepted Answer

Yes. Controllers define routesMeta() once — this single definition is used for REST route registration, ability auto-derivation, and OpenAPI 3.0 spec generation. The documentation is always in sync with the actual API because they share the same source.

Question 35

What happens during a schema CRUD request?

Accepted Answer

Every data operation passes through a four-stage pipeline: (1) Sanitize — type-based cleaning for text, email, URL, and other field types, (2) Validate — schema rules including required, minLength, pattern, enum, and custom callbacks, (3) Writable filter — field-level write permissions based on role and operation type (create vs update), (4) Readable filter — field-level read permissions with secret field masking. Secret fields return a hasValue indicator instead of actual values.

Frequently asked questions.

About Enravo

Platform & Architecture

Trust & Security

Client · App · Device

Technical Details

Still have questions?

Rakton

Enravo Trust