Kitodo.Production 4.0

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_D2s_v4 (2 vCPU / 8 GiB RAM) is a sensible starting size, because the image runs three JVM-backed services (Tomcat, OpenSearch and MariaDB). Size up for heavier production workloads and larger collections.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp for the web interface. Also allow 443/tcp if you add TLS. Kitodo is served over plain HTTP by default, so for production put your own domain and a trusted certificate in front of it (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Kitodo.Production by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80). Then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms once per subscription, then create the VM.

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:kitodo-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name kitodo \
  --image sac1647283583153:kitodo-ubuntu-24-04:default:latest \
  --size Standard_D2s_v4 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

After the VM is created, open port 80 to reach the web interface:

az vm open-port --resource-group <your-rg> --name kitodo --port 80 --priority 900

Step 3 - Connect to your VM

Connect to the VM over SSH as azureuser.

ssh azureuser@<vm-public-ip>

The first boot rotates the administrator password and prints a summary to the message of the day. Your first SSH session therefore shows the web interface URL and the location of the credentials file.

Step 4 - Confirm the services are running

Kitodo runs on Tomcat behind nginx, backed by MariaDB and OpenSearch. Confirm that all four services are active, that Tomcat and OpenSearch are bound to the loopback interface, and that the health endpoint answers:

systemctl is-active mariadb.service opensearch.service tomcat10.service nginx.service ss -tlnp | grep -E '127.0.0.1:8080|127.0.0.1:9200|:80 ' curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/healthz

Step 5 - Retrieve your admin password

The per-VM testAdmin password is written to a root-only file at /root/kitodo-credentials.txt (mode 0600). On first boot, the well-known default testAdmin / test credential is rotated away and the seeded demo accounts are deactivated. Read the file with sudo:

sudo cat /root/kitodo-credentials.txt

Step 6 - Sign in to the Kitodo web interface

Open http://<vm-public-ip>/kitodo/ in your browser. Kitodo redirects you to its sign-in page. Sign in as testAdmin with the password from the credentials file.

Step 7 - Explore the desktop

After you sign in, you land on the Kitodo desktop. It summarizes your tasks, processes and projects and shows database statistics. A worked "Example Project" ships with the image, so you can see the layout immediately.

Step 8 - Manage projects, workflows and rulesets

Use the Projects area to configure the building blocks of a digitization workflow: projects, production templates, workflows, dockets, rulesets, import configurations and mapping files. Adapt the shipped example to your own material and metadata rules.

Maintenance

• Add a domain and TLS. Kitodo is served over plain HTTP on port 80 by default. For production, point a DNS name at the VM and terminate TLS in front of it, for example with a certificate from your own CA or Let's Encrypt through a reverse proxy or the Azure Application Gateway. Never expose the plain HTTP endpoint to the public internet for real collections.
• Database and search backend. MariaDB (database kitodo) and OpenSearch are both bound to the loopback interface and are reachable only by Kitodo on the VM. Back up the MariaDB kitodo database regularly. If needed, rebuild the search index from the database on Kitodo's indexing page.
• Configuration. Kitodo's rulesets, OPAC configuration, XSLT and other configuration live under /usr/local/kitodo. The web application is deployed at /var/lib/tomcat10/webapps/kitodo##4.0.0.
• Users. The shipped image has a single active administrator (testAdmin) with the per-VM password. Create additional users and roles in the Users area of the web interface. The seeded demo accounts are deactivated, and you can re-enable them there if you want the example users.
• Security updates. The image is patched at build time and ships with unattended-upgrades enabled, so OS security updates continue on your VM.

Support

Every SecureAnyCloud image comes with 24/7 support. For help deploying or operating Kitodo.Production, contact SecureAnyCloud support.

Deploy on Azure

Launch Kitodo.Production 4.0 on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com