Extending Flexkit

The Studio ships with its four apps built in: Desk, Asset Manager, Explorer and AI. Its interface is not extended from code. There is no extension registry, no custom form field or preview registration, and no navbar or command contribution point. The Studio renders the schema that flexkit deploy published for each project, and that deployed schema is where its behaviour comes from.

Why the UI is not extended from code

The Studio is becoming a hosted application, with a desktop app to follow, that renders the deployed schema of every project a member can access. Because no project bundles its own copy of the UI, an upgrade reaches every project at once without a redeploy of the host application. Business rules live in the schema (menu groups, field groups, validation, conditional visibility) and in the agent layer (custom tools, plugins, skills, automations) instead of in client code, so the same rules apply whether a record is changed by an editor in Desk, by an agent in Chat, by an automation or through the API.

Flexkit remains extensible; the extension points moved to the server side and to your own applications.

Migrate from Studio extensions

If your application registered an extensions array, apply these steps once:

1. Remove @flexkit/desk, @flexkit/asset-manager, @flexkit/explorer and @flexkit/ai from your dependencies. They are deprecated on npm; their apps and public types are part of @flexkit/studio. Import one stylesheet, @flexkit/studio/styles.css, and delete the per-package styles.css imports.

2. Delete flexkit.studio.tsx, together with every defineExtension, StudioExtension and StudioContributions usage. flexkit.config.ts is pure data: title, projectId, menuGroups, scopes, spaces and schema, with defineConfig and defineEntity imported from @flexkit/schema. Icons are lucide icon names (menu.icon: 'Tag'), hidden and readOnly are booleans, and validation: (z) => ... is compiled to JSON Schema on deploy. See schema configuration for the full list of removed keys.

3. Mount the Studio with project ids instead of a config object. The host application never imports flexkit.config.ts; the Studio fetches each project’s deployed schema after login.

   app/studio/[[...slug]]/page.tsx

   Copy

   import { FlexkitStudio } from '@flexkit/studio';
   import '@flexkit/studio/styles.css';
    
   export default function Studio() {
     return <FlexkitStudio projectIds={['your-project-id']} basename="/studio" />;
   }

   basename replaces the former basePath config key; omit it when the Studio lives at /. Run flexkit deploy after every change to flexkit.config.ts; until the first deployment the project has no entities, so Desk is empty.

4. Review attributes that used a custom inputType or previewType. They now render as text. Model the rule in the schema instead: a select with option values, a number with validation, a conditional field or a field group.

5. Rebuild custom apps as standalone applications. A contributed app becomes its own page or application that calls the GraphQL API with an API token from a server, or renders beneath FlexkitStudio with the exported hooks (useEntityQuery, useEntityMutation, useUploadAssets, useSearch) when it needs the signed-in member’s authority. See the Studio reference.

Ways to extend

Agents and integrations that need the entity list can read it from the schema endpoint with a member session, or through the MCP search_schema tool. UI visibility is never a substitute for server authorization: roles, spaces and project restrictions are enforced by the API whichever path a change takes.