Get started

Getting started

Two ways in: a machine of your own, or Exeora Cloud. Both end with a URL to point a client at.

On this page

Exeora connects an AI client to a project: a repository with a working copy on a machine, where an agent can read, edit and run things. There are two ways to give a project a machine, and neither is the lesser one. A machine of your own keeps the code where it already is. Exeora Cloud clones the repository onto an instance, a machine Exeora runs, so an agent can work with nothing of yours switched on. A project can use both, and you can add the second one later.

A machine of your own#

curl -fsSL https://exeora.dev/macos/install.sh | sh
exeora connect
exeora project add
exeora connect
exeora project add the-project-you-want-to-serve

That is the whole setup. connect opens a browser to sign in if you are not signed in and registers the machine if it is not registered. It does not have to run inside a project directory. exeora project add registers a directory to serve, where it is. Each step is skipped when it is already done, so running connect again just connects.

Nothing is uploaded, no port is opened, and no tunnel is configured, because the CLI dials out to the gateway and holds that connection open. Nothing ever dials in, which is why the same command works on a laptop behind NAT and on a box behind a corporate firewall.

exeora project add also takes a repository instead of a directory: exeora project add owner/repo clones it into this machine's projects folder, ~/exeora unless you chose another, and registers the clone. The first time connect runs at a terminal it asks where that folder should be.

It prints an MCP URL. Point a client at it, and leave connect running: nothing on this machine is served while it is not.

The installer selects the release for your operating system and CPU, verifies its SHA-256 checksum, and puts exeora on your PATH. The Linux binary needs glibc 2.31 or newer: Ubuntu 20.04 LTS, 22.04, 24.04, Debian 11 and later, current Fedora releases, and RHEL 9 and later.

Later, run exeora upgrade. It downloads the newest release for your platform, verifies the published checksum, and securely replaces the current binary.

Exeora Cloud#

This way starts in the dashboard and needs no CLI. Exeora Cloud is enabled per account by an administrator while there is no billing, so an account that does not have it yet is told so where the choice is offered.

  • First, sign in to the dashboard and open Settings. Under GitHub, choose Connect GitHub and pick, on GitHub, which repositories Exeora is given. See connecting GitHub.
  • Then open Projects and choose Add project. Pick the repository from the list. There is no address to type and no token to paste.
  • Last, choose Exeora Cloud as the place it lives first. Exeora clones the repository onto an instance and connects the CLI there.

The project's page shows its MCP URL as soon as the project exists, and the state of the instance until it is ready. A repository on another Git server is added from the same dialog, with its https address and, when it is private, a token. See Exeora Cloud.

An instance comes with the tools an agent expects to find, gh signed in as you among them. A project can run a script when an instance is set up and another every time it resumes. See what an instance comes with and scripts.

What a project is#

A project is a repository. It lives in one or more locations: your machines and Exeora Cloud. One location is the default, and a call that names no workspace lands there. A workspace is a branch with a working copy of its own, in one location. See projects, locations and workspaces.

A project is removed only when you remove it. One that has a repository and loses its last location, because a machine was deleted or an instance was destroyed, stays with its MCP URL, its policy and its clients. It lives nowhere until it is given a place again.

The boundary every tool is confined to is the project's directory in the location the call lands on: the project root, or the working copy of the workspace the call names. An agent cannot read, write or run anything outside it through a path: paths are resolved and checked against that directory before anything touches the disk.

The CLI refuses to register your home directory or the filesystem root, because either would make that boundary the whole machine.

Each project gets its own URL and its own token. A token minted for one project is not accepted at another, so "this client may work on that repository" is a sentence you can say one repository at a time. It covers the project wherever it lives: every location, and every workspace in them.

There is also one URL that covers several, https://exeora.dev/mcp, so a client can be configured once instead of once per project. You choose which projects it may reach when you authorize it, and it names the project on each call. See which URL to use.

What it can do to a machine#

A new project allows everything. Until you narrow it, an agent connected to a project can read, edit and write any file inside that directory and run any command there. That is worth knowing before you connect the first one.

From the dashboard you can set a project to read only, name the commands it may run, refuse specific commands in any mode, choose which tools exist at all, and ask to confirm every change before it happens. See what a project allows.

Whatever you decide, revoking a machine from the dashboard cuts its connection immediately rather than at the end of whatever it was doing.

Type to search every page.