Directus for Internal Tools: Admin Panels on Your SQL DB

Directus is a good fit for internal tools when you already have a SQL database and need a secure, role-aware admin panel on top of it fast. It connects to your existing tables and gives you a data app, REST and GraphQL APIs, granular permissions, and no-code automation, all without migrating data or rewriting your schema. It is a poor fit when the tool is mostly bespoke workflow UI, or when your licensing situation rules out a source-available product.

Below is what we weigh when a CTO asks whether to use Directus, a custom admin, a Retool-style builder, or Strapi. If you want a team to scope it with you, our Directus development services page covers how we handle these projects.

How Directus wraps an existing database

Most admin tooling asks you to model your data inside the tool. Directus works the other way around. You point it at a supported SQL database (PostgreSQL, MySQL, MariaDB, SQLite, Microsoft SQL Server, Oracle and CockroachDB are all supported) and it introspects the schema that is already there. Tables become "collections," columns become "fields," and foreign keys can be configured as relations.

A few things are worth understanding before you connect it to anything important:

• Your tables stay yours. Directus does not wrap your rows in its own storage format. A row in orders is still a row in orders, readable by your existing services, reports and ETL jobs.
• It adds its own system tables. Directus creates tables prefixed with directus_ for users, roles, permissions, activity, revisions, files, flows and UI metadata. Plan for that in your naming conventions and backups, and keep it in mind if another tool manages migrations on the same schema.
• UI metadata is separate from schema. How a field is displayed lives in Directus's metadata, so a raw status varchar column can become a clean select box without an ALTER TABLE.
• Schema changes made in Directus are real DDL. Adding a field in the Data Model screen alters the underlying table. On a shared production database, restrict that to admins and route schema changes through your normal migrations.

The practical effect: a team with a Postgres database behind a customer app can have a back-office panel for support and finance within days, without changing the app.

The APIs come for free

Every collection is exposed through REST and GraphQL, with filtering, sorting, pagination and relational queries, governed by the same permissions as the admin panel. You can start in the Directus data app and later build a purpose-made front end against the same secured API instead of writing a second backend.

Roles and permissions: where Directus earns its keep

Internal tools fail audits more often than they fail functionally: support can see salary data, or a contractor can bulk-delete records. The permission model is the main reason we recommend Directus for sensitive back-office work.

Permissions are defined per collection and per action (create, read, update, delete, share), and you can go further than on/off:

• Field-level access. A support role can read customers but not the tax_id or credit_limit fields.
• Item-level rules. Access can be limited by a filter, so a regional manager only sees rows where the region matches their own profile.
• Validation and presets. You can require that updates satisfy a rule, and pre-fill fields on create (for example, stamping created_by with the current user).
• Reusable access policies. Newer Directus versions group permissions into policies that can be attached to roles or directly to users, which makes "base staff access plus a finance add-on" much easier to express than duplicating whole roles.

An item-level rule uses the same filter syntax as the API, with dynamic variables for the current user. A read permission on orders restricted to the user's region looks like this:

{
  "region": {
    "_eq": "$CURRENT_USER.region"
  }
}

Directus also records activity and revisions for changes made through it, so you get "who changed this invoice, and what was it before" without building an audit table. Writes from your other services bypass it, so keep database-level auditing if you need a complete trail.

Authentication supports local accounts plus SSO through OpenID Connect, OAuth 2.0, LDAP and SAML, which usually covers whatever identity provider the company already runs.

Flows: automation without a separate workflow tool

Flows are Directus's built-in automation engine. A flow starts from a trigger and runs a chain of operations, passing data between steps. Triggers include:

• Event hooks, such as an item being created or updated in a given collection. These can run blocking (before the write, able to modify or reject it) or non-blocking (after the write).
• Webhooks, so an external system can call into Directus.
• Schedules, using cron syntax.
• Manual triggers, which appear as a button in the data app for selected items.
• Another flow, so you can compose reusable sub-flows.

Operations cover conditions, reading and writing items, sending email, sending in-app notifications, making HTTP requests, transforming payloads, logging, and running a small JavaScript script for anything the built-ins do not handle.

Typical examples: a refund above a threshold is set to "pending approval" and finance gets a notification; a nightly schedule refreshes exchange rates; a manual "Resend welcome email" button on customers calls your email provider.

Our opinion: flows are excellent for short business rules owned by an operations team. Once a flow grows branching, retries and error handling across several systems, it becomes hard to review and test visually. Move that logic into a code extension or backend service and keep the flow as a thin trigger.

Extensions: when the defaults run out

Directus is built on Node.js and Vue, and nearly every part of it is extensible. The extension types you will actually use for internal tools:

You scaffold an extension with npx create-directus-extension@latest. Here is a custom endpoint that respects the caller's permissions by passing their accountability into Directus's own services:

import { defineEndpoint } from '@directus/extensions-sdk';

export default defineEndpoint((router, { services, getSchema }) => {
  const { ItemsService } = services;

  router.get('/overdue', async (req, res, next) => {
    try {
      const invoices = new ItemsService('invoices', {
        schema: await getSchema(),
        accountability: req.accountability,
      });
      const rows = await invoices.readByQuery({
        filter: { status: { _eq: 'overdue' } },
        sort: ['due_date'],
        limit: 100,
      });
      res.json({ data: rows });
    } catch (err) {
      next(err);
    }
  });
});

Using ItemsService with req.accountability, rather than raw SQL, keeps custom code inside the permission model; code that goes straight to the database is how internal tools quietly lose access controls. Extensions are ordinary Node.js and Vue code, so a team comfortable with Node.js development can own them without learning a proprietary scripting language.

Directus vs custom admin vs Retool-style tools vs Strapi

Here is how the four options compare on the questions that usually decide it:

Choose Directus when

• The data already lives in a SQL database and the tool is mostly "view, search, edit, approve" on that data.
• Different teams need different slices of the same tables, and field- or row-level access matters.
• You want an API over the same data for other apps, not just a UI.
• You want to self-host for data residency or compliance reasons.

Build a custom admin when

• The internal tool is really a product: heavy, task-specific workflows where the screen does not resemble a table or a form.
• Performance or UX requirements are strict (high-volume operators processing hundreds of items an hour benefit from purpose-built keyboard-driven screens).
• Business logic is complex enough that you want it all in one tested codebase. Our custom CMS development work covers this route.

A useful middle ground: use Directus as the backend (auth, permissions, API, audit) and build only the custom screens that need it on top of its API.

Choose a Retool-style builder when

• You need many small tools that stitch together several APIs and databases, and non-backend engineers will build them.
• Per-seat pricing works for your headcount and a hosted vendor is acceptable.

The trade-off: these builders sit on top of your data sources rather than providing a secured data layer, so row-level security is usually your job in each query.

Choose Strapi when

• The primary job is managing content for websites and apps, and you are designing the data model from scratch.

Strapi is a strong headless CMS (we are a Strapi Community Partner and built Colleges18 and Schools18 on Strapi and Next.js), but it wants to define and own its content types. Pointing it at an existing operational database with tables your other services write to is not what it is designed for. For a deeper look at the two, see our Strapi vs Directus comparison.

Hosting and self-hosting considerations

You can run Directus on the vendor's managed cloud or host it yourself. Self-hosting is common for internal tools because the database is usually already inside a private network. The official Docker image is the standard route. What to plan for:

• Network placement. Directus needs a direct database connection. Run it inside the same VPC or private network, put it behind your VPN or SSO-protected proxy if it is staff-only, and do not expose the admin publicly unless you have a reason to.
• Database user. Give Directus a dedicated database user. It needs DDL rights to manage its own system tables and run upgrades; if you want to stop it altering your business tables, that is a permissions design exercise at the database level worth doing up front.
• Horizontal scaling. For more than one instance, configure a shared cache and rate-limiter store (Redis) and a shared file storage driver (S3-compatible, Google Cloud Storage, Azure) instead of local disk.
• Secrets. Directus is configured through environment variables; keep keys and credentials in your secrets manager, not a committed .env.
• Upgrades. Directus ships frequently, and major versions have included breaking changes to extensions and permissions. Pin the image version, read the release notes, and test upgrades against a copy of production. Upgrades run migrations on the directus_ tables, so take a backup first.
• Environment promotion. Directus configuration (collections, fields, relations) can be exported and applied with the schema snapshot commands, for example npx directus schema snapshot ./snapshot.yaml and npx directus schema apply ./snapshot.yaml. Roles, permissions and flows live as data in system tables, so decide how you will move those between staging and production before you have many of them.

A note on licensing

Directus is not open source in the OSI sense. Since moving from GPL to the Business Source License (BSL), its source code is public and you can self-host and modify it, but production use by larger organizations requires a commercial license. The free tier is aimed at smaller organizations, with eligibility based on the organization's overall size (such as total annual revenue and funding) rather than on how you use Directus. Under the BSL model, each release also converts to an open-source license after a set period.

We do not quote the thresholds because the vendor sets them and they may change. Read the current terms and have legal review them if you are near the line. The commercial license is often still cheaper than maintaining a custom admin, but it does change the comparison with Retool-style tools or a custom build.

A pre-adoption checklist

1. Confirm your database engine and version are supported, and test introspection on a copy of the schema first.
2. List every role that will use the tool and the fields and rows each must never see.
3. Decide who can change the data model in Directus (ideally nobody in production).
4. Identify which rules belong in flows, which in hook extensions, and which already live in your backend and should stay there.
5. Check whether other services write to the same tables, and whether Directus's audit log is sufficient or you need database-level auditing.
6. Choose hosting: managed cloud or self-hosted, with network placement, SSO, Redis and file storage planned.
7. Confirm licensing eligibility or budget for a commercial license.
8. Set an upgrade cadence and a staging environment before launch, not after.

If you are weighing Directus against other headless options more broadly, our headless CMS development team can help you compare them against your actual data model.

FAQ

Can Directus connect to an existing PostgreSQL or MySQL database without migrating data?

Yes. Directus introspects the existing schema and works on your tables in place. It adds its own directus_ system tables to the same database but does not copy or restructure your data. Test against a staging copy first to review how your tables and relations are detected.

Is Directus secure enough for internal admin panels with sensitive data?

Its permission model is a strength: access can be restricted per collection, action, field and row, with SSO and an activity log. Security still depends on deployment, so keep it on a private network and route custom code through Directus services.

Is Directus free for commercial use?

It depends on the size of your organization. Directus uses the Business Source License, which allows free use for smaller organizations and requires a commercial license above a size threshold. Check the current terms on the Directus website, as the details are set by the vendor.

Directus or Retool for internal tools?

Choose Directus if you want a secured data layer (permissions, API and audit) over one main SQL database and prefer self-hosting. Choose a Retool-style builder if you need many small drag-and-drop apps spanning several data sources and are comfortable with a hosted, per-seat product.

If you have an existing database and a growing list of back-office requests, a scoped Directus rollout is often the quickest way to give each team a safe, well-permissioned tool. Our Directus CMS development team can review your schema, access requirements and hosting setup and tell you plainly whether Directus, a custom admin, or a mix of both is the better route.