Connect your code: change, check, approve, deploy, and roll back a real codebase

Name the project, then paste the repository's address (from GitHub's green Code button) and the branch the site runs from, usually main. Choose how aiKit reaches it. GitHub token: a fine-grained token you make on GitHub for this one repository with Contents set to Read and write; it goes with an https:// address. Deploy key: a key pair made only for this repository, whose public half you add under the repository's Settings, Deploy keys, with Allow write access ticked; it goes with a git@ address. Public repository: read only, so approved changes have nowhere to be saved; use it only to look around.

You paste the token or key yourself. It is stored encrypted on aiKit's engine and never shown again, to anyone. The page only ever shows a fingerprint. Connect the repository copies the code to the engine and reads what kind of project it is (Laravel, JavaScript, or static files). Nothing in the repository changes.

A project you already have can be connected too: on its Hosting tab, the owner sees Connect your code.

Your own server: the site stays exactly where it is. Enter the server's address, the SSH port (usually 22), the login aiKit uses (the setup steps make one called aikit), the site's folder (for a Laravel Forge site, /home/forge/your-site.com), the deploy command the site already uses (usually bash scripts/deploy.sh), and the pages that must answer after every deploy, one full address per line. Paste the server login's private key (made in setup step 1). Save and check the connection.

The first time aiKit reaches the server it shows the server's fingerprint and asks Is this your server? Compare it with what the server printed in setup step 6. Only press It matches. Connect when they are identical. From then on a different server at that address is refused. When the check passes, the page says which version the server runs right now.

aiKit hosting: aiKit builds and serves the code itself, with a free address to start. Best for sites and front ends.

Under Server setup the page lists eight copy-and-paste steps, already filled in with your values; each has a Copy button. Steps 1 and 8 run on your computer, steps 2 to 7 on the server as a user with sudo.

What they build: a login with no password and no shell (step 2). Its one key is locked to a small gate script (steps 3 and 5) that accepts exactly two commands: status (which version runs, and whether the site is in maintenance mode) and deploy of one exact commit. Deploy runs as the site's own user through one sudo rule, checks that the branch on GitHub points at that exact commit, then runs your existing deploy script unchanged. Step 4 sets folder permissions so the login reaches only the site folder: not the other sites in the same home folder, and never .env. Step 7 tests all of it and says what you should see for each line, and step 8 tests the login from your computer before you paste its key into aiKit.

If a server hosts other businesses too, this is the point: the aiKit login can deploy this one site and nothing else. The site's code still runs as the site's user, exactly as it does when you deploy from GitHub yourself, which is why every change is reviewed and why risky files are protected.

Four tiles at the top. Repository: the repository, branch, the newest commit, and the kind of project. Runs on: your own server (with the login and when it last answered) or aiKit hosting. Live release: the release the site runs, who made it, and when. Pages: how many of the pages that must answer did answer at the last check; Check now visits them again, and any page that didn't answer is listed underneath with what it returned.

Below the tiles: Request a change (or the change that is open right now), Releases, Change log, Protected files, and, for the owner, Connection.

Type what should change, naming the page and what you want to see, and press Make the change. The card turns into Change #1 with live progress: getting the latest code, the files the AI reads and edits, then each check. The AI only edits files; it runs no commands. One change is open at a time per project, and each request counts toward the project's AI limit.

When it finishes you see: the request and who asked; what the AI says it did; the checks, each with a tick or a cross and its output; Preview buttons for the checked pages; the files with Added, Changed or Removed and a Protected badge where one applies; and the diff, file by file, green for added lines and red for removed lines. That diff is exactly what will be committed and deployed.

Approve and deploy (owners and builders) commits the change to the branch with a message that names who asked and who approved, pushes it (never forced: if someone pushed meanwhile, the change is marked Out of date and nothing deploys), deploys it, and checks the pages. Discard throws the change away after a confirmation; nothing was deployed. Reviewers can read everything and press neither.

After the checks pass is a setting under Connection, Checks and review. Wait for approval is the default. Deploy automatically deploys a change by itself only when every check passed and no protected file changed; anything else still waits.

For a Laravel project the checks are: every changed PHP file parses (php -l); every Blade view compiles (php artisan view:cache); the front end builds (npm run build); and the app starts on a test run with a throwaway SQLite database, migrated and seeded from the repository, where each page in Pages the test run must open answers 200. They run on aiKit's engine, never on your server and never against your live database. The project's .env file is never copied or read; the test run gets throwaway settings.

A failed check blocks Approve. The owner alone can tick Deploy even though checks failed, for a check that failed for a reason that doesn't affect the live site.

Preview opens the changed app from the test run in a new tab, with test data and forms switched off. It stops 15 minutes after its last use and ends when the change is approved or discarded.

The AI leaves protected files alone. The list starts with: migrations that already ran on the live site (every migration in the live release, since each deploy runs them), new migrations (they would change the live database on the next deploy), the deploy script, and the dependency files (composer.json, composer.lock, package.json, package-lock.json). Each entry says why. The owner adds a file or folder (config/** means everything under config) with a reason, removes entries, and presses Save protected files.

To change a protected file on purpose, the owner ticks Allow protected files for this request. The change then shows which protected files it touched, and only the owner can approve it, after ticking Yes, deploy the changes to protected files. A builder who ticks nothing gets no protected access.

.env files, private keys and auth.json are in a stricter tier: never read, never changed, never part of a diff, and nobody can switch that off.

The first time aiKit reaches your server it records what the server runs as release 1, Before aiKit, so even aiKit's first deploy can be rolled back. After that, every deploy is a numbered release: Change (an approved change; its name opens that change), Redeploy, or Rollback, with its commit, who did it, its status (Live, Earlier, Live but pages failing, Deploy failed), how many pages answered, and the deploy log. aiKit keeps the last 5.

Deploy the latest code deploys whatever is newest on the branch right now, after a confirmation, for example when someone pushed a fix directly.

Roll back to this, on an earlier release, makes a new commit whose files are exactly that release's, pushes it, and deploys it the normal way, then checks the pages. History is never rewritten, so the rollback itself can be rolled back.

Every request with its number, the request, who asked, who approved or discarded it, when, and where it stands. Press a row to open that change with its checks and diff; the address gets ?change=<id>, so you can share the link with your team.