Your apps. On your server.
From a form to an AI agent, you build with the open Ara-Kit the apps that Arasul runs on your server.
Company knowledge for agents and internal apps
Arasul keeps the company's knowledge as a single folder for coding agents and hosts the internal apps next to it on the same server. The two belong together, so an agent works with the knowledge and the workflows of your business. How the apps reach the internet, how backups work and how an update runs is in the same cards.
The company folder
The company's knowledge sits as a file tree on the server. Permissions come per folder and person in four levels: none, read, write, at the server. Staff sync the folder to their workstation over Tailscale, and the admin manages tree and permissions in the frontend and sees who changed what. Anyone working with Claude Code or Codex reads the folder as context.
The apps
Internal apps take over the deterministic part, meaning the workflows that should run the same way every time. Arasul hosts them and signs the staff in. Each person only sees the apps an admin has assigned to them, and no technical detail: they confirm approvals inside the app, and only a fault shows a sentence. Whoever builds needs no technical term, because the kit asks about roles, internet and model in plain language.
The bridge
The bridge lets an agent in the folder work with the apps. A credential belongs to one person, also works outside the browser and can be revoked by the admin. Every app describes itself for agents, and a command-line tool in the folder calls them, on Windows too. The interface of every app sits under /apps/<name>/api/.
The control
The admin decides who signs in and which apps a person sees. The permissions per folder and person define what an external agent gets to see from the folder. That is how you decide what leaves the server.
Outbound control
Every app runs in its own network without internet. It reaches only its own database and the Arasul interface. An outbound proxy lets through only the destinations listed in app.json under verbindungen, and logs per app. On the Connections page the admin sees what is entered, what was used and what was refused.
Backup
Only the admin sees an attached SSD, and confirms it once. After that an encrypted snapshot is made every night, writing only what changed, kept for 7 days, 12 weeks and 60 months. The company folder is part of the backup. In the frontend the admin restores the whole server, one app or the company folder, with a password and after a backup of the current state. During setup Arasul shows a recovery code to print, which a factory reset and a new server need.
Updates
The admin installs a new version with one button or switches on installing at night, without a technician and without SSH. Arasul makes a backup first, shows progress and knows the way back to the previous version. Data, license, apps and folder stay. New versions belong to the optional maintenance.
Handover
A kit repo that belongs to the customer carries apps, the server's record and the profile, without secrets. Whoever clones it creates their own keys, and the old ones are revoked. This works the same in Claude Code and in Codex.
What an app is on Arasul
An app is not a construction kit and not a plugin frame, but a package of four parts whose shape the server dictates.
01 A manifest
Every app has an app.json: name and version, what memory and compute it gets and which models it may use. The server reads it on rollout.02 A page
Arasul serves the frontend under /apps/<name>/. Whoever is signed in and has the app assigned sees it in the rail on the left, otherwise not.03 A container
The backend runs as its own container on the server. Arasul hands it the signed-in person, so it does not have to handle sign-in itself.04 Flows in the same package
A flow is a markdown file next to the app and is versioned with it. It runs traceably and can pause until a human approves.
You describe it. The AI builds it.
01 You describe
An app for leave requests with approval by the manager
02 The kit builds the package
- leave-requests/
- app.json
- page/
- container/
- flows/
03 Arasul shows the app
Leave requests
Every app sits in two states on the server: test and live, so you try out a new version before it applies to everyone.
What you can build
A few examples that work in almost every business. Open them up. What is possible is decided by the need.
Leave requests that no longer sit in the inbox
Situation
Leave is requested by email and someone keeps a list. Who is off right now, nobody knows reliably.
How it runs
- 01The employee files the request in the app, which sits on the server.
- 02A flow checks the remaining leave and overlaps in the team.
- 03The manager gets the request in their overview and decides there.
- 04Afterwards the request stands at approved or declined, with date and name.
What it gives you
One workflow instead of an email chain. This app sits in the Ara-Kit as a complete example and can be taken as a template.
Quotes and invoices, without retyping
Situation
A request comes in and someone builds the quote by hand. Look up line items, look up prices, format. Whoever answers faster wins the deal. Later the same for the invoice.
How it runs
- 01The request lands in the inbox or in the form you use anyway.
- 02A flow reads out what is needed. It calculates with the business's price list.
- 03The quote comes back as a PDF and waits for approval.
- 04Once the order is through, it becomes the invoice, directly as a ZUGFeRD e-invoice.
What it gives you
Quote and invoice take minutes instead of an evening. Calculation and customer data stay on the server.
Answers from your records
Situation
The same questions come in every day. Delivery time, invoice, how does feature X work. The answers have long been in your records. Just spread across manuals, emails and heads.
How it runs
- 01You build an app that reads in your manuals and old email threads and keeps them searchable.
- 02A flow pulls the answer from exactly these sources, not from the open web.
- 03For standard questions a draft reply is created, with the source location.
- 04Approve, adjust, send. Nothing goes to the customer unchecked.
What it gives you
Answers in minutes instead of the next day. Important: you build this app yourselves, Arasul does not bring it along. The search index belongs to the app and sits on your server.
Two programs that finally talk to each other
Situation
Accounting runs in one program, the tax advisor works in another. In between sit exports, emails and follow-up questions. And nobody has an overview of the numbers in real time.
How it runs
- 01The app reads the data from the program where it already sits, for example the accounting software Lexware.
- 02A flow prepares it the way the other program needs it and hands it over, for example to DATEV, the software many German tax advisors work in.
- 03Recurring filings and tax preparation run largely on their own. You only approve.
- 04The key figures show up in a dashboard that runs as its own app on the server.
What it gives you
What is pieced together by hand every quarter today happens on the side. The key figures sit in one place and stay on the server.
Build what is missing.
The Ara-Kit is open and free and needs no account. Arasul on the server adds sign-in, approvals and operations.