4aee115bf4
# [1.6.0](https://gitlab.com/oceanbox/fornix/compare/v1.5.1...v1.6.0) (2025-12-19) ### Features * update to always enable pgsql and add readme ([7bf938a](7bf938a249))
README
This template scaffolds a web application with the following components configured:
Server
- Saturn
- Giraffe
- OpenIdConnect, JWT and plain authentication
- Fable.Remoting
- Fable.SignalR
- Dapr
- Prometheus metric
- Tilt
Client
- Fable.Lit
- Fable.Remoting
- Fable.SignalR
Deployment (Drupal on Kubernetes)
We treat Git as the source of truth for any Drupal code, dependencies, and configuration. The idea is to keep the Kubernetes Drupal instance reproducible and avoid config mismatches.
What must be included in the container image
When adding a new feature or changing configuration, these files and folders are required deployment in the Kubernetes cluster:
composer.jsonandcomposer.lockdrupal/config/(exported Drupal config)
If any of these are missing or out of date, there will typically be missing module errors, config import failures, or mismatches between environments.
Export config locally
Use this when you changed configuration locally (UI changes, enabling modules locally, content type changes, views, permissions, etc).
drush cex
Commit the updated drupal/config/ output.
Import config in Kubernetes
Use this when drupal/config/ changed in Git and you deployed a new image (or synced a new revision).
drush cim -y
drush cr
drush cim imports the repo config into the running site. drush cr clears caches so changes are reflected immediately.
It can also be done through the Drupal admin UI, under Configuration -> Development -> Configuration Synchronization.
Composer dependencies
If added, removed, or updated PHP packages, composer.lock must be updated and the container must run a Composer install during the image build.
composer install
Avoid config mismatch in the cluster
We should try to avoid changing config directly on the Kubernetes Drupal instance because drush cim can overwrite manual changes.
Using Dapr
This template includes support for Dapr Actors. The custom use_multiauth and use_oidc authentication pipelines configure the user (principal) groups and roles (claims) via a UserActor, which can easily be migrated to an external Dapr service if need be.
Install the Dapr CLI and set up Dapr for use with actors:
dapr init -s
cp .dapr/components/* ~/.dapr/components
Run the development server(s) under Dapr:
dapr run --app-id webapp --app-port 8085 -- dotnet run