Internal operations platform
Operations teams handle their own data. Engineers stay on the product.
Admin as a Service connects directly to your company databases. Engineering defines each operation once, and business teams use it through generated forms or purpose-built screens. Every execution is permission-checked, scoped to an environment and recorded in the audit log.
- No more manual SQL on production
- New tools go live the moment you publish
- Dedicated deployment for every customer
Works with
- PostgreSQL
- MySQL 8
- SQL
- JavaScript
- React + TSX
- Cron
- RUN find-orders · env=production · ✓
- PUBLISH update-status · v3 · SQL guard ✓
- DENY delete-order · role=viewer · logged
- JOB daily-report · cron 0 1 * * * UTC
- BULK update-prices · up to 10,000 rows per run
The problem
A single “can you look up this order?” request can cost an engineer half a day
How it works today
- Support sends lookup requests to engineering and waits hours for an answer.
- Operations staff keep their own SQL scripts and run them by hand on production.
- Every new admin screen takes a development sprint and a deployment.
- Database passwords are widely shared, and nobody can tell who changed what.
With Admin as a Service
- Engineering defines an action once; business users run it themselves through a form.
- SQL is validated at publish time, and parameters are always bound, never concatenated.
- A new screen goes into use with a single publish, without a deployment.
- Connection credentials are encrypted and never sent to the browser. Every execution is logged.
How it works
Three steps from database to operations tool
Generated forms cover most day-to-day operational needs. For complex workflows, engineering builds dedicated screens in React.
- STEP_01
Connect a data source
Register PostgreSQL or MySQL with separate settings for dev, staging and production. Test the connection and browse tables and relationships directly in the browser.
- STEP_02
Define actions
Write SQL with parameters such as {{status}}, or orchestrate several actions in JavaScript. Actions are saved as drafts, validated on publish and versioned.
- STEP_03
Put them to work
Authorized users run actions through forms generated from their parameters, on demand or on a schedule. High-volume write operations can run in the background or in bulk.
Features
Connect, execute and control from one platform
The capabilities internal data operations depend on, designed to work together from the start.
-
Data sources and relationship diagram
PostgreSQL and MySQL with per-environment settings and TLS support for CA and client certificates. Tables, columns and foreign keys are shown as a diagram.
-
SQL and JavaScript actions
Typed parameters, option lists sourced from other actions, and transformers that render links and images. JavaScript runs in an isolated sandbox.
-
Generate CRUD from a table
Select a table and the operations you need: list with search, sorting and paging; view; create; update; delete. The platform creates draft actions for engineering to review.
-
Generated run forms
Forms are built from parameters, and write actions always require confirmation. Write actions run in bulk with up to 10,000 parameter sets. Results export to CSV.
-
Views in React/TSX
An editor with type hints for every action, instant preview, and a drag-and-drop layout builder that generates starter code. Publishing includes a type check.
-
Drafts, versions, rollback
Edits on a draft never affect what users are running. Each publish creates an immutable version that can be compared and restored.
-
Background jobs and schedules
Track progress on long-running tasks and cancel them when needed. Cron schedules can target several environments at once.
-
Separate dev and production
Every project starts with dev and prod. New actions stay off production until enabled, and the navigation bar turns red in production.
-
Variables and secrets
Per-environment configuration values used directly in actions. Secrets are write-only and are not displayed again after saving.
-
Granular access control
Admin, editor and viewer roles; user groups; per-action run permissions; per-environment access with role limits.
-
Audit trail
Records every configuration change and every execution, including denied attempts. Filter by user, event, environment, outcome and date, then export.
-
Bilingual interface
Vietnamese and English, light and dark modes, and multiple color palettes chosen per user.
Build
A complete set of operations for any table in a few clicks
The Tables & diagram page shows your real data structure. From any table, the platform generates a CRUD set of draft actions, and engineering reviews the SQL before publishing.
- Relationship diagram laid out from foreign keys
- Lists with search, sorting and paging
- SQL validated on publish, before it reaches users
Self-service operations
Business staff look up and update data without writing queries
Every published action has its own run page: a form generated from its parameters, results in a table, and CSV export. High-volume write operations run in the background or in bulk.
- Write actions always require confirmation
- Bulk runs of up to 10,000 parameter sets
- Execution history kept for every action
Custom screens
Dedicated business screens, live without a deployment
Views are written in TSX with type hints for every action and an instant preview, or started from the drag-and-drop layout builder. After publishing, users reload the page to get the new version.
- Type checking on publish
- Views run in an isolated frame with the viewer’s own permissions
- Versioning and rollback, as with actions
Control
Know who ran what, in which environment, and when
Run permissions are granted per action and per environment. Production is clearly marked. Every execution, including denied attempts, appears in the audit log.
- Open or restricted run permission for each action
- IP allowlists and role limits per environment
- The log records row counts, not data contents
Roles
Clear responsibilities by role
Four roles, from organization administrators to business users.
-
Owner
Administers the organization: creates projects and manages user accounts.
-
Admin
Administers a project: members, groups, environments, data sources, deleting actions and the audit log.
-
Editor
Builds: writes actions, manages variables and secrets, designs views and creates schedules.
-
Viewer
Uses: runs permitted actions, opens screens and follows jobs. Cannot see SQL or data sources.
Security
Security built into the architecture
A tool with access to production data needs tighter controls than any other internal system.
-
Encrypted connection credentials
Passwords and certificates are protected with envelope encryption (AES-256-GCM) and decrypted only on the execution server. Stored values are never returned to the browser.
-
SQL validated on publish
Parameters are always bound and never concatenated into statements. Multiple statements, DDL, and writes inside read-only actions are rejected before they reach users.
-
Custom code in a sandbox
JavaScript runs in a WebAssembly sandbox with no file or network access. Views run in an isolated iframe on a separate origin and cannot read the login session.
-
No implicit privileges
Publishing a view grants viewers no additional permissions. Users can only run actions they are personally allowed to run. Permissions are enforced at a single point.
-
Every execution logged
Each execution, including denied attempts, records who ran it, when, in which environment and with what outcome. Returned data is not stored.
-
Isolation per customer
Each customer has a dedicated environment for configuration data, encryption keys, domain and a fixed egress IP address for your database allowlist.
Use cases
One platform for every department
-
Customer support
Answer customers while they are still on the line
Agents look up orders by ID, phone number or status themselves. Data access is limited to the permissions they have been granted.
-
Operations
Controlled bulk updates
Update the status of thousands of orders in a single bulk run, with confirmation before writing and an audit record afterwards.
-
Finance and data
Scheduled recurring reports
Schedule revenue and reconciliation actions. Export results to CSV for further work in spreadsheets.
-
Internal tools engineering
A dedicated screen for each department
Build dashboards, approval tools and multi-step workflows in React, and put them into use with a single publish.
Deployment
Dedicated infrastructure for each business
Every customer runs an independent installation. Configuration data, encryption keys, domain and egress IP are never shared with other customers.
-
Isolated per customer
A separate configuration database and encryption keys for each customer.
-
Fixed egress IP
Allowlist a single IP address to let the platform reach your databases.
-
Implementation support
Our team works with you to connect the first data source and build your priority tools.
Roadmap
- Actions that call HTTP/REST APIs
- Single sign-on (SSO/SAML)
- Gateway deployed inside your VPC
- Approval before sensitive actions run
- Audit log streaming to your SIEM
FAQ
Frequently asked questions
Do business users need programming skills?
No. Users fill in a form and click Run, or open a ready-made screen. Defining actions requires SQL (or the generate-CRUD-from-a-table feature). Building custom views requires React.
Which data sources are supported?
PostgreSQL and MySQL (version 8.0 and later), each with per-environment settings and TLS support for CA and client certificates. HTTP API data sources can already store settings and test connections; actions that call HTTP APIs are on the roadmap.
Does the platform store our business data?
No. Execution history and the audit log record the user, action, time, environment, parameters (with sensitive values masked), outcome and row count. Returned data is not stored. Connection credentials are encrypted and never sent to the browser.
How do we prevent accidental writes on production?
New actions are not applied to production by default, and enabling production requires confirmation. Write actions always require confirmation before they run. Production is shown in red. Run permission can be limited to specific users or groups.
Does editing an action affect the people using it?
No. All edits happen on a draft while users keep running the published version. Each publish creates a new version, and you can restore an earlier version at any time.
What does the platform save compared with building admin pages in-house?
Engineering no longer rebuilds login, permissions, audit logging, environment management, background execution and data export for every tool. Effort goes into queries and business screens, and publishing requires no build or deployment.
Is single sign-on (SSO) supported?
SSO/SAML is on the roadmap. Currently, accounts are created and managed by the organization owner, and login sessions can be revoked on every device.
How do we get started?
Book a demo. Our team will connect a test data source with you and build your first tool together. The documentation describes the full workflow on the platform.
Give operations the tools. Give engineering its time back.
A 30-minute demo built around your own business scenario.