doc(README): better description of slim Murena Workspace

# Murena Workspace

# slim Murena Workspace

This project builds a custom docker image from the official [Nextcloud](https://nextcloud.com), applying patches to make Murena Workspace.

![Murena Workspace preview](docs/murena-workspace.png)

2 images are available the `default` and the `slim` ones.

slim Murena Workspace is a curated Nextcloud build tailored for Murena’s collaboration needs and fully aligned with /e/OS mobile so users can sync files seamlessly across devices.

This repository extends the official [Nextcloud](https://nextcloud.com) image with custom patches, entrypoints, and configuration helpers so you can spin up a production-like stack locally or in CI with minimal friction.

## Getting started

## Highlights

### Local environment

- **Nextcloud + Murena extras** – curated defaults that ship with the Murena experience out of the box.

- **Single slim image** – streamlined to stay lean while keeping the key collaboration apps enabled.

- **Dynamic configuration** – every service toggle lives in environment variables, no Dockerfile edits needed.

- **Scale with shared storage** – horizontal replicas are possible once you point the stack to shared config/data volumes.

- **Integrated observability** – ships with syslog and Sentry wired in by default so errors surface quickly.

- **Proxy-ready** – works out of the box behind Traefik (or similar reverse proxies) for production HTTPS routing.

- **/e/OS continuity** – themes and bundled apps mirror the /e/OS mobile experience so files, contacts, calendars, notes, and tasks stay in sync.

- **Ops-friendly assets** – `.env` templates, hook directories, and helper scripts that speed up staging or CI bootstraps.

You can configure default values from the `.env` file. See [.env.example](./.env.example).

## Core apps

By default, the `slim` Murena Workspace is configured.

`slim` Murena Workspace

- 📫 [Mail](https://gitlab.e.foundation/e/infra/ecloud/nextcloud-apps/snappymail)

```

- 📁 [Files](https://github.com/nextcloud/server/tree/master/apps/files)

cp .env.example .env

- 👥 [Contacts](https://gitlab.e.foundation/e/infra/ecloud/nextcloud-apps/contacts)

docker compose up --build -d

- 📆 [Calendar](https://gitlab.e.foundation/e/infra/ecloud/nextcloud-apps/calendar)

```

- 📝 [OnlyOffice](https://github.com/ONLYOFFICE/onlyoffice-nextcloud)

- ✍️ [Notes](https://github.com/nextcloud/notes)

- ✅ [Tasks](https://github.com/nextcloud/tasks)

Go to http://localhost:8000 then use admin credentials provided into `.env` file.

## Quick start (users)

### Swarm environment with managed storage and services

```bash

cp .env.example .env          # only required the first time

docker compose up -d          # pulls the published slim image automatically

```

Then open http://localhost:8000 and sign in with the admin credentials defined in your `.env`.

No build step is needed for regular users—the compose stack pulls the published slim image directly from the registry.

First create the context:

## Developer workflow

```

If you need to tweak the image (patches, entrypoints, additional apps):

docker context create dev --description "Development environment" --docker "host=ssh://root@dev.domain.app"

docker --context dev service ls

```bash

cp .env.example .env

docker compose up --build -d   # rebuilds the image locally with your changes

```

```

Secondly, once the .env configuration file initiated create the deployments stack:

Use this mode when integrating or patching apps, adapting entrypoints, or testing new Nextcloud releases.

```

## Configuration

docker stack deploy -c <(docker compose --env-file=.env config --no-normalize | sed '1d') instance-name

```

- Copy `.env.example` to `.env`, then adjust ports, storage paths, secrets, and feature toggles.

- Need more juice? hook the stack to managed databases or caches by updating the relevant env variables, no rebuild required.

- Object storage ready: set the S3-compatible env vars (AWS S3, MinIO, etc.) to offload files without touching the image.

- Syslog and Sentry endpoints are prewired—just tweak the env vars if you need to point them somewhere else.

## Coding conventions

- Follow [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) for commit messages; this keeps changelogs and automated releases predictable.

- Embrace the [12-factor](https://12factor.net/) guidelines: configuration via environment variables, stateless processes, and disposable deployments are already baked in, so contributions should preserve that behavior.