gpatruno/homeceti repository overview

⁠Homeceti

The self-hosted access portal for your services — built for homelabbers and small teams alike.

⁠What is Homeceti?

Homeceti is a self-hosted personal dashboard (in the spirit of Homarr or Homepage) that brings together all your access points — internal services, self-hosted apps, web shortcuts — in one place, for one or many users with their own permissions.

Each user gets their own customizable grid of services and folders, while an administrator keeps control over who sees what.

⁠Why Homeceti?

• Multi-user with granular access — each service can be assigned to one or several users independently of the others.
• OIDC/SSO compatible — plugs into an existing identity provider (Keycloak, Authelia, Auth0, Okta...), handy for integrating with an authentication system a small team or organization already runs.
• Security built in — anti brute-force rate limiting on login, automatic IP blocking for vulnerability-scanner traffic, optional antivirus scanning of uploaded files (ClamAV), HTTP security headers (Helmet).
• Lightweight and easy to deploy — a single Docker image (~70 MB, Alpine) plus a PostgreSQL database, and you're up.
• Customizable — light/dark theme, per-user accent color or background image, instance-wide branding (logo, background).
• Flexible organization — folders, drag-and-drop, instant search across all services and shortcuts.
• Login traceability — per-user list of connected devices, last activity, remote session revocation.

⁠Features

• Personalization
  • User: background (color or image), avatar
  • Service: logo, background image, display order, note
• User management
  • Connected device tracking
  • Per-user, per-service access
  • Roles (admin / user)
  • Account activation / deactivation
• Service management
  • Activation / deactivation
  • Local-network and LDAP-protected service indicators
  • Favicon fetching from the service URL
• Domain management
  • Whitelist of authorized domains, with pending validation
• Shortcut management
  • Personal shortcuts, organizable into folders
• Security
  • Anti brute-force protection on login
  • Automated scan blocking (WordPress paths, .env, .git...)
  • Optional antivirus scanning of uploaded files
  • Secure server-side sessions
• Authentication
  • Local account (JWT) or delegated to an OIDC provider

⁠Roadmap

• Customizable email templates
• UI language selection
• Automatic service assignment via LDAP integration

⁠Who is it for?

• Individuals / homelabbers — a single entry point to your self-hosted services, accessible from any screen.
• Small teams, non-profits, SMBs — an internal portal that's simple to deploy, with per-user access control and SSO integration to lean on an authentication system you already run.

⁠Tech stack

• Backend: Node.js 22, Express 5, PostgreSQL 15 (Sequelize, automatic migrations via Umzug)
• Frontend: Angular 20, Angular Material, TailwindCSS
• Deployment: Multi-stage Docker build (final Alpine image ~70 MB)

⁠Quick start

docker-compose up -d

⁠Docker Compose

Exemple de configuration docker-compose.yml :

services:

  postgres:
    image: postgres:15
    container_name: postgres-home
    ports:
      - 5432:5432
    environment:
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PWD}
      POSTGRES_DB: ${DB_NAME}
    networks:
      nethome:
        aliases:
          - postgres

  homeceti:
    image: gpatruno/homeceti:latest
    container_name: homeceti
    ports:
      - 3000:3000
    environment:
      DB_NAME: ${DB_NAME}
      DB_USER: ${DB_USER}
      DB_PWD: ${DB_PWD}
      DB_HOST: postgres
      PUBLIC_URL: https://homeceti.domain.name
      SESSION_SECRET: secret-for-session
    volumes:
      - ./path/to/logs:/app/logs:rw
      - ./path/to/uploads:/app/resources/uploads:rw
    depends_on:
      - postgres
    networks:
      nethome:
        aliases:
          - homeceti

  # Optionnel — active le scan antivirus des uploads (voir section "Antivirus" ci-dessous)
  # Nécessite d'ajouter CLAMAV_HOST: clamav dans les variables du service homeceti
  # clamav:
  #   image: clamav/clamav:stable
  #   container_name: clamav
  #   volumes:
  #     - clamav_definitions:/var/lib/clamav
  #   networks:
  #     nethome:
  #       aliases:
  #         - clamav
  #   healthcheck:
  #     test: ["CMD", "clamdscan", "--ping", "1"]
  #     interval: 30s
  #     start_period: 120s

networks:
  nethome:

volumes:
  homeceti:
  postgres:
  # clamav_definitions:

⁠Variables d'environnement

⁠HTTP vs HTTPS — comportement de PUBLIC_URL

Le protocole de la variable PUBLIC_URL pilote automatiquement deux mécanismes de sécurité côté serveur. Il n'y a pas d'autre variable à régler : il suffit de renseigner l'URL réelle par laquelle les utilisateurs accèdent au dashboard.

Pourquoi c'est nécessaire. Si l'on sert l'application en HTTP nu (ex. http://192.168.1.25:3000) alors que ces deux mécanismes restent actifs :

• la directive CSP upgrade-insecure-requests force le navigateur à recharger les ressources (JS, CSS) en https://, ce qui échoue sur un serveur sans TLS → page blanche + ERR_SSL_PROTOCOL_ERROR ;
• le cookie de session secure n'est jamais transmis sur HTTP → impossible de rester connecté.

En déduisant le mode du protocole de PUBLIC_URL, ces deux écueils sont évités automatiquement.

⁠Volumes

⁠Premier démarrage

Au premier démarrage, rendez-vous sur http://<PUBLIC_URL>/init pour créer le compte administrateur.

⁠License

Distributed under the MIT⁠ license.