# Access and modes

Managing application visibility and server mode. The access policy (`accessPolicy`) determines who in Bitrix24 can open the application's HTTPS subdomain: only the owner, a list of specific users and departments, all Bitrix24 account users, or any visitor at all. The server mode (`mode`) toggles between Black Hole (everything closed behind the firewall) and OPEN (direct access by IP).

> **Changing `accessPolicy` from `OWNER_ONLY` to a more open value directly affects security.** Never do it on a user's behalf without explicit confirmation — it opens the application to other people in the Bitrix24 account or to the entire internet.

Scope: `vibe:infra`

## Operations

- [SSH credentials](./access/ssh.md) — `GET /v1/infra/servers/:id/ssh`
- [Switch mode](./access/mode.md) — `PATCH /v1/infra/servers/:id/mode`
- [Access policy](./access/access-policy.md) — `PATCH /v1/infra/servers/:id/access-policy`
- [Access list](./access/access-list.md) — `GET /v1/infra/servers/:id/access`
- [Add user/department](./access/access-add.md) — `POST /v1/infra/servers/:id/access`
- [Delete access entry](./access/access-delete.md) — `DELETE /v1/infra/servers/:id/access/:accessId`
- [Search Bitrix24 users](./access/b24-users.md) — `GET /v1/infra/servers/:id/b24-users`

## Access policies (from the most closed to the most open)

| Policy | Who sees the HTTPS subdomain |
|----------|--------------------------|
| `OWNER_ONLY` | Only the API key owner (default) |
| `NAMED_USERS` | Users from the access list |
| `DEPARTMENT` | Bitrix24 departments from the access list |
| `PORTAL` | All Bitrix24 account users |
| `AUTHENTICATED` | All authenticated users (including non-members of the Bitrix24 account) |
| `PUBLIC` | Everyone, without authentication |

## Typical scenario (NAMED_USERS)

Open the application for specific Bitrix24 employees:

1. Find users: [`GET /b24-users?search=Jane`](./access/b24-users.md).
2. Switch the policy: [`PATCH /access-policy`](./access/access-policy.md) `{ accessPolicy: "NAMED_USERS" }`.
3. Add a user: [`POST /access`](./access/access-add.md) `{ type: "user", userId: "243", userName: "Jane Smith" }`.
4. Check the list: [`GET /access`](./access/access-list.md).
5. Later — delete the entry: [`DELETE /access/:accessId`](./access/access-delete.md).

## "Restore privacy" scenario

1. Switch the policy back to `OWNER_ONLY`: [`PATCH /access-policy`](./access/access-policy.md) `{ accessPolicy: "OWNER_ONLY" }`. User and department entries remain in the database but are no longer applied.
2. If you need to clear the history — delete all entries via [`DELETE /access/:accessId`](./access/access-delete.md).

## See also

- [Lifecycle](/docs/infra/lifecycle) — start/stop/wake/repair.
- [Root section — Infrastructure](/docs/infra) — overview of policies, statuses, errors.