uvdesk/community-skeleton: the five packages you inherit and the host you inherit with them

Five packages decide what you inherit from the skeleton

uvdesk/community-skeleton is not an application you clone and run. It is a Composer skeleton: the top level carries composer.json alongside config/, public/, src/, templates/ and translations/, which is the shape of a Symfony project reduced to what an install can boot. Everything a support desk needs arrives as a separate package you require, and the README divides them into five roles. One core framework holds the APIs the other packages depend on. A separate extension framework exists so third-party packages can add behaviour, an automation bundle carries workflows and prepared responses, and a mailbox component turns inbound email into support tickets. Customers meet the support center bundle, the portal they write to.

The browser side is backbone.js. Its primary language is CSS rather than PHP, which is a fact about asset weight rather than about where the logic sits. Server side, the code is Symfony, with bundles under apps/ and services under src/, so PHP is where your changes land.

The mailbox component turns inbound email into tickets

Email is the front door. The Mailbox Component converts incoming mail into support tickets, and the feature list claims no limit on the number of mailbox or email integrations attached to one install. Around that intake path sit the controls an agent actually touches: filtering by status, ID, agent and customer, ticket forwarding, email notifications, email templates, saved replies, notes for agents, pinned threads, multiple attachments, ticket types and multiple tags.

None of it is configured inside the repository. Every mail parameter arrives through environment variables, and the sample file ships the transport credentials blank, so the mailbox component cannot move a single message until you fill in a host, a port, a username, a password and an encryption mode. A support desk whose tickets arrive by email therefore depends on mail server credentials you supply, not on anything bundled here.

The image runs php8.1 inside apache2 instead of a php-fpm pool

The Dockerfile at the top level starts from an unpinned base and installs its own stack rather than expecting one. These are the lines that decide the runtime:

FROM ubuntu:latest
ENV GOSU_VERSION=1.11
RUN apt-get update && \
    add-apt-repository -y ppa:ondrej/php && \
RUN adduser uvdesk --disabled-password --gecos ""
RUN a2enmod php8.1 rewrite && \
COPY ./.docker/bash/uvdesk-entrypoint.sh /usr/local/bin/
COPY . /var/www/uvdesk/

Because the PHP module is loaded into the web server, requests execute PHP inside apache2 itself. There is no php-fpm pool and no separate boundary for the database, since mysql-server is installed into the same image. Two consequences are worth weighing before you build. PHP execution shares the apache2 worker pool, so a heavy request holds a worker other customers wait on. And ubuntu:latest moves under you, which means two builds from the same commit can land different library versions, while the vhost copied out of .docker/config/apache2/ decides whether the rewrite module and the docroot behave the way the installer expects.

One detail is done properly. The build downloads gosu 1.11 for the detected architecture and verifies it against an OpenPGP key, then uses it to step down from root to a non-root `uvdesk` account instead of running the service as root.

Three version signals disagree about what this repository currently is

The version numbers here do not agree with each other, and picking the wrong one costs an afternoon. Three files named `CHANGELOG-1.0.md`, `CHANGELOG-1.1.md` and `CHANGELOG-1.2.md` sit at the top level, while the newest tag is v1.1.8 and the sample environment file still declares `APP_VERSION=1.0.8`. Nothing in the repository states which of those is authoritative, so the tag you clone may not match the code you configure.

A second signal sits in the topic tags, which still read symfony4 while the container installs php8.1. Read that tag as what the project calls itself rather than as a description of the runtime you get. Commits reached the default branch master on 2026-10-05, after the newest tag landed on 2025-09-19, so work has continued past what any tag contains. The feature list also names a user friendly web installer, and running it is the only way to settle the question, because the version it reports is the one your database and templates were built against.

The sample environment file ships debug on and a test relay

Everything the install needs to talk to arrives in one sample file, and it is committed at the top level next to the working `.env`. This is the block you copy first:

APP_NAME=UVDesk
APP_ENV=local
APP_VERSION=1.0.8
APP_KEY=
APP_DEBUG=true
APP_URL=http://localhost
APP_TIMEZONE='Asia/Kolkata'
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=
DB_USERNAME=
DB_PASSWORD=
DB_PREFIX=

Two defaults will bite. APP_KEY is empty, so nothing is encrypted until the installer generates one, and APP_DEBUG=true combined with APP_ENV=local answers a misconfigured request with a stack trace instead of a page. A third one bites later: the database host is 127.0.0.1 on port 3306, which is right for a single-host install and wrong the moment you move the database off the box. DB_PREFIX exists for installations that share a database server with other software.

Installing means filling a blank sample file and following an outside guide

This repository ships no single install command, and the documentation steps are not inline either. Installation is routed outward: the link row near the top of the README points to docs.uvdesk.com and to a separate installation guide hosted on the uvdesk site for Ubuntu. A file named `INSTALLATION GUIDE.md` also sits at the top level. Budget an external read before you budget the install.

What you can copy verbatim is the configuration you must fill in. Take these transport keys before anything else, because both the mailbox component and the automation bundle stop early without them:

BROADCAST_DRIVER=log
CACHE_DRIVER=file
SESSION_DRIVER=file
SESSION_LIFETIME=20
QUEUE_DRIVER=sync
MAIL_DRIVER=smtp
MAIL_HOST=smtp.mailtrap.io
MAIL_PORT=2525
MAIL_USERNAME=
MAIL_PASSWORD=
MAIL_ENCRYPTION=tls

QUEUE_DRIVER=sync runs automation jobs inside the request that queued them rather than in a background worker, so a slow workflow makes the agent wait. BROADCAST_DRIVER=log writes ticket update events to the log instead of pushing them to a connected browser, so two agents watching the same ticket see nothing live. Set MAIL_USERNAME and MAIL_PASSWORD for the host you use, and move MAIL_HOST off the shipped smtp.mailtrap.io on port 2525 before a customer reply can land in a shared testing inbox.

Agent privileges and the extension framework are where your code goes

Customization here is a package boundary, not a settings page. The extension framework exists for third-party package integration and development, and the knowledge base stores content as articles, categories and folders that you shape yourself. Branding is equally manual: change the logo, change the favicon, ship your own email templates. What the install hands you is prepared responses and standard automated workflows, which cover routine cases and leave the rest to you.

Agent privileges decide what each agent may do, and collaborators let you pull extra people into a ticket. Agent activity records what they did, which is the audit trail most teams look for first. The feature list also names a reCAPTCHA option and a block-spam switch for the public entry points, ticket types and multiple tags for triage, and a broadcasting message for announcements. The README header carries 11 language flags next to the top-level translations/ directory, so translation files ship with the skeleton rather than arriving later.

The wrong fit when you do not want to run the database yourself

The topic tags file this repository as an osticket-alternative, a freshdesk-alternative and a zendesk-alternative, which is the project's own positioning rather than a measured comparison. Read it as a statement about approach: everything runs on infrastructure you already pay for. The image installs apache2, mysql-server and php8.1 into one container, so a single host carries the web server, the database, the mail transport and the ticket store, and patching, upgrading and backing up all land on you.

Two costs follow from that shape. A mysql-server living inside the application image has no replication, and the credentials it uses are the same ones sitting in your environment file, so a restored backup is the only other copy of your ticket history that exists by default. If your workload needs mail retry queues, read replicas or a support contract covering the stack, this skeleton hands you none of it. Teams that only need a shared inbox and a place to track replies get more from keeping the mail server and database with a managed provider than from running this.

Distribution runs under an OSL-3.0 licence, in `LICENSE.txt` at the top level next to an `INSTALLATION GUIDE.md` whose filename carries a space. Anyone scripting against this repository has to quote that name, so budget for it in a build script rather than discovering it during a container copy.

Editorial conclusion

Adopt this skeleton when you already operate a LAMP host and want ticket intake, agent privileges and a customer portal without buying a product. Walk away if the team expects someone else to patch apache2, mysql-server and the PHP runtime, because every one of those boxes lands in your server room. Before writing code against it, open `.env.example` and decide which of the repository's three version signals describes your branch, then set MAIL_HOST to a relay you control before the mailbox component starts turning customer replies into tickets.

Frequently asked questions

Official sources

1. License: OSL-3.0
2. Project website
3. README
4. Releases
5. uvdesk/community-skeleton on GitHub