Webfolio is a Maven based monorepo containing:
- A Quarkus backend
- An Angular frontend with Tailwind, DaisyUI, and Vitest
The repository is structured to keep backend and frontend concerns separated while still providing one build system and a simple local development flow.
The root project is a Maven parent that:
- aggregates all modules
- centralizes dependency and plugin management
- keeps versions aligned across backend and frontend
- Quarkus application
- Java 21
- runs in dev mode via
mvn quarkus:dev
- Angular application
- Tailwind CSS and DaisyUI
- Vitest for unit testing
- managed via npm and Maven plugins
The backend exposes a Model Context Protocol server at /mcp using the Quarkus MCP Server extension with Streamable HTTP transport.
The server provides the following capabilities:
- Resources — the full OpenAPI specification of the WebFolio API, served as JSON at
webfolio://openapi - Tools — search endpoints by keyword and retrieve detailed information about a specific path
- Prompts — reusable prompt templates for API onboarding, contact form integration, debugging, and API review
The MCP server is intended for local development and AI tooling only. It is not exposed publicly in the production Docker Compose setup.
Point your MCP client to:
http://localhost:8080/mcp
For VS Code, add the following to .vscode/mcp.json:
{
"servers": {
"webfolio": {
"type": "http",
"url": "http://localhost:8080/mcp"
}
}
}- Java 21
- Maven
- Node.js LTS via
nvm
This project uses two different configuration flows.
For local development, create a .env file at the repository root.
Example:
TELEGRAM_API_BASE_URL=https://api.telegram.org
TELEGRAM_BOT_TOKEN=0000000000:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
TELEGRAM_CHAT_ID=00000000
TZ=Europe/Berlin
WEBFOLIO_IMAGE=ebarooni/webfolio:latestYou can copy the values from .env.example and replace the Telegram placeholders with real values.
The .env file is used for local development by startup.sh. In that flow, the script reads:
TELEGRAM_API_BASE_URLTELEGRAM_BOT_TOKENTELEGRAM_CHAT_ID
and passes them to Quarkus as JVM system properties.
That means local development does not use Docker secrets.
Docker Compose uses the root .env file only for Compose level variables such as:
WEBFOLIO_IMAGETZ
The application secrets for the container do not come from .env.
They come from the file configured in compose.yaml:
secrets:
app_secrets:
file: ./secrets/application-secrets.propertiesCreate that file at:
./secrets/application-secrets.properties
Example content:
telegram.chat.id=00000000
quarkus.rest-client.telegram-api.url=https://api.telegram.org/bot0000000000:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAInside the container, Compose mounts that file as:
/run/secrets/app_secrets.properties
Quarkus is configured to read it through:
environment:
QUARKUS_CONFIG_LOCATIONS: file:/run/secrets/app_secrets.propertiesImportant:
- the values inside
./secrets/application-secrets.propertiesmust be real resolved values - placeholders such as
${TELEGRAM_BOT_TOKEN}inside that file are not expanded by Docker Compose .envis not a templating mechanism for secret files
Start the local development environment from the repository root:
./startup.shThis is the canonical local development entrypoint. It reads .env, resolves the Telegram related values, and starts Quarkus with the required system properties.
From the repository root:
mvn -pl backend quarkus:devIf you start the backend manually, you must pass the required Telegram properties yourself or provide them through another valid Quarkus config source.
From the frontend module:
npm install
npm run startTo run the containerized application, make sure both of these files exist:
.env./secrets/application-secrets.properties
Then start Compose as usual.
The responsibilities are split as follows:
.envprovides Compose variables./secrets/application-secrets.propertiesprovides application secrets for Quarkus inside the container
mvn clean installFrom the frontend module:
npm testIf Homebrew is not installed, follow the official installation instructions.
Then run:
brew updatebrew install openjdk
java --versionbrew install maven
mvn -vInstall nvm according to the official instructions, then run:
nvm install
nvm useCheck the installed versions:
node -v
npm -vCreate a feature branch:
git checkout -b feat/<short-description>Start the development environment:
./startup.shKeep changes focused and cohesive. Prefer small, well scoped pull requests.