Ship the frontend with your agents.
Sign-in and data access built in.
Build a chat, a review inbox or an internal tool with any framework that outputs static files. connic builds it on every deploy, serves it per environment and signs people in with connic accounts or your identity provider.
From the ops console to the customer portal.
Your operations team, your reviewers and your customers each get the app they need. Every app signs people in its own way, calls agents through its connectors and reads only the data its rules allow.
Run volume, failures and pending approvals across all agents, with a cancel button for stuck runs.
Reviewers see what an agent wants to do and why, then approve or reject it.
Customers report a claim, upload photos and follow the status while an agent assesses it.
Upload a contract and get findings per clause, saved to your database and open to follow-up questions.
Each visitor sees only their own data.
An employee and the IT team open the same app and send the same request. The employee gets their own tickets and the IT team gets all of them, because connic adds the app's access rules to every query.
- Rules filter the query
doc.author_id == user.idbecomes part of the database query, so lists, counts and pages hold only the visitor's own records.- Fields the browser can't set
setwritesauthor_idon every insert, and connic rejects updates that try to change it.- Denied unless a rule allows it
- Requests without a matching rule get a 403, and a rule that can't be enforced fails the deploy, with the file and the rule's path in the error.
- Refusals you can see
- Each app's stats show 30 days of visitors, sign-ins and data requests, with failed sign-ins and denied requests counted on their own.
Decide who can open each app.
Customers open a public assistant, reviewers sign in with their connic account, and employees use the company login they already have. Set the sign-in per environment in the app file, or in the dashboard without a deploy.
- Public
- Anyone with the link, for customer-facing assistants, intake forms and demos.
- connic accounts
- Project members, optionally limited to permission groups. A good fit for staging and internal review tools.
- Your identity provider
- Employees sign in through your OpenID Connect provider, limited by email domain or group, without a connic account each.
One deploy ships the app and the agents it calls.
Put the source in apps/it-desk/ and describe the app in apps/it-desk.yaml. Every deploy builds it together with the agents it calls, and each environment serves it at its own connic.app address.
name: IT desk
build:
command: npm run build
output: dist
auth:
mode: oidc
issuer: https://sso.example.com
client_id: ${DESK_CLIENT_ID}
client_secret: ${DESK_CLIENT_SECRET}
allowed_domains: [example.com]
connectors:
- desk-chat
access:
database:
tickets:
read: doc.author_id == user.id or "it-support" in user.groups
insert: user.signed_in == true
set:
author_id: user.id
environments:
Staging:
auth:
mode: connic
Production:
domain: desk.example.combuild
connic installs the dependencies from your lockfile and runs
npm run buildon Node 22 or 24. If the build fails, so does the deploy, and the active deployment keeps serving.auth
oidcsends people to your identity provider, andallowed_domainsadmits only company addresses. Leaveauthout to manage sign-in in the dashboard.connectors
The app reaches agents only through the connectors listed here. With
apps_only: truein its file, a connector takes requests from nothing else, and a WebSocket connector streams the reply into the browser while the agent writes it.access
Employees read their own tickets, the it-support group reads all of them, and
setfills inauthor_idon every insert.environments
Staging signs in with connic accounts. Production keeps your identity provider and serves the app on
desk.example.com.