# Overview in five minutes

Organizations, projects and the generated repositories, the path from push to production, and the two ways of working form the frame in which you work with the platform as a developer.

> Source: https://www.application-platform.com/en/docs/developer-overview/

From a project configuration, the platform generates GitLab repositories with a code scaffold, pipelines and deployment configuration and runs everything from `git push` to the running container; your part is the product code.

## Organization, project and repositories

An **organization** holds members, billing, servers, store accounts and connections such as Sentry, Cloudflare or SMTP; administrators manage it, developers work on their projects. A **project** is one product inside it and gets a GitLab group on `gitlab.application-platform.com` with one repository per component, `gitlab-profile` for the README and two platform-maintained repositories:

- `local-configuration` holds the editor and agent configuration (`AGENTS.md`, `CLAUDE.md`, `.cursor`, `.claude`, `.codex`, `.vscode`) and is symlinked into the project folder.
- `gitops-configuration` describes, per environment (dev and prod), which version runs with which configuration; the pipelines write the versions into it, your own values go into `custom.yaml`.

## From push to production

```mermaid
flowchart LR
  push["Push or merge to main"] --> pipeline["Pipeline: test, version, build"]
  pipeline -->|"automatic"| dev["Dev"]
  pipeline -->|"manual job"| prod["Prod"]
```

A push or merge to `main` starts the pipeline, which derives the version from the commit messages (`feat:`, `fix:`), builds the artifact and records the state in `gitops-configuration`; dev is rolled out automatically, production through a manual job in GitLab, and feature branches build without a version commit. [Git workflow and deployment]({{< relref "git-workflow" >}}) describes the flow including rollback.

## Where things live

In the **web interface** at `app.application-platform.com` you manage organizations, **Projects**, **Servers**, **Connections**, **Docker Apps**, **Domains** and **Workspaces**. **GitLab** holds the code, pipelines, job logs and merge requests, and **Sentry** collects errors once a Sentry account is connected under **Connections**. How Ansible, image tags and servers interact is covered in [Architecture]({{< relref "architecture" >}}).

## Two ways of working

Locally, the [setup app]({{< relref "local-app" >}}) prepares your machine and clones all repositories into `~/Documents/application-platform/<organization-slug>/<project-slug>/`; alternatively you work in a [remote workspace]({{< relref "workspaces-overview" >}}), an Ubuntu VM in the cloud. In both cases you open the project folder in your editor and start each application with `ap run-local` from the repository root, see [Local development]({{< relref "local-development" >}}) and [CLI and agent plugin]({{< relref "cli-and-agent-plugin" >}}). Then you [create a new project]({{< relref "create-project" >}}) or [import an existing repository]({{< relref "agent-project-import" >}}).