Stud.IP

Search the Azure Marketplace for Stud.IP Learning Management on Ubuntu 24.04 LTS by SecureAnyCloud and select Create.

Choose your subscription, resource group and region. Select the recommended size Standard_B2s (2 vCPU, 4 GB).

Set the administrator username to azureuser and provide your SSH public key.

On the Networking tab, allow inbound port 80 (HTTP) and port 22 (SSH).

Select Review + create, then Create. When the VM is running, note its public IP address.

Accept the Marketplace terms, create a resource group and the VM, then open ports 80 and 22:

RG="studip-prod"; LOCATION="eastus"; VM_NAME="studip" IMAGE_URN="sac1647283583153:studip-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:studip-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 80 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

On the first boot, the image runs these steps:

• Imports the Stud.IP schema and generates this VM's database password.
• Rotates the root@studip administrator to a unique password.
• Opens the bootstrap gate and starts the web server.
• Verifies that the new credentials work and that root@studip/testing is rejected.
• Writes /root/studip-credentials.txt.

This completes within a minute or two. SSH in as azureuser and read the details:

sudo cat /root/studip-credentials.txt

The file is mode 0600 and owned by root, so only a privileged user can read it. It contains the platform URL, the administrator username (root@studip) and password, and the database name, user and password.

Run the commands below. All three services should report active. The ss output confirms that the platform is on port 80 while MariaDB is bound to loopback only. The response headers carry no server version banner.

systemctl is-active mariadb.service php8.3-fpm.service nginx.service php -r 'echo "PHP ".PHP_VERSION."\n";'
sudo mysql -N -e "SELECT CONCAT('MariaDB ', VERSION())" nginx -v ss -tlnp | grep -E ':(80|3306) ' | sed 's/users:.*//' | sort curl -sI http://127.0.0.1/dispatch.php/login | head -3

Browse to http://<your-server-ip>/ and sign in with the username root@studip and the password from your credentials file.

On your first sign-in, Stud.IP asks you to accept its terms of use. It then opens your personal desktop, the hub with your courses, your schedule, messages, announcements and quick links to every tool.

The desktop confirms that the whole stack works end to end: the web server, PHP and the database are all answering.

Open the avatar menu (top right) and go to Settings > Password to set your own password. The administrator account is the one Stud.IP calls a root user, and it can reach the whole Admin area.

You can also change any user's password from the command line:

cd /usr/local/studip printf '<new-password>\n<new-password>\n' | sudo -u www-data php cli/studip user:password root@studip

Open the Admin area (the cog in the top navigation). This is where you configure your institution. From here you build out your campus:

• Create and manage user accounts and roles.
• Create institutes and course categories.
• Manage the semesters and the course catalog.
• Configure the available tools and global settings.
• Moderate content.

Go to Admin > Courses > New course. As a lecturer, you can use the + in the top bar instead. Give the course a name, pick a semester and a course type, and create it.

Each course opens with its own tools, which you enable per course: participants, documents and folders, a forum, a wiki, a schedule and news. Enroll participants directly, or open the course for self-enrollment with an optional access code.

Stud.IP runs scheduled work, such as notification digests and cleanup tasks, through a cronjob worker. The image ships the worker as a systemd timer that fires every minute, so there is nothing to configure. Confirm that the timer is active:

systemctl is-active studip-cron.timer
systemctl list-timers studip-cron.timer --all --no-pager

A fresh appliance relies on the local mail transport. To send mail through your own SMTP server, set the mail options in config/config_local.inc.php.

The relevant keys are $MAIL_TRANSPORT, $MAIL_HOST, $MAIL_PORT, $MAIL_USER and $MAIL_PASSWORD. Add them for your provider at <your-domain> and clear the cache. The Stud.IP administration documentation has the full mail configuration reference.

Point an A record at your VM's public IP. Stud.IP builds absolute URLs from the request Host header, so the new hostname needs no configuration change. Then install a certificate with Certbot:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d studip.<your-domain> --redirect --agree-tos -m you@<your-domain>

Certbot edits the nginx site in place and reloads it. The packaged timer renews the certificate automatically.

nginx and php8.3-fpm are each gated on the bootstrap marker /var/lib/sac/data/studip-bootstrap-ready, which the first boot creates only after the schema is imported, the per-instance database password is written and the root@studip account is rotated. Until then, systemd skips those units, so the transient root@studip/testing default is never reachable. Both units are still enabled, so the platform returns after a reboot. Verify the gate and the unit state:

grep -H ConditionPathExists /etc/systemd/system/{nginx,php8.3-fpm}.service.d/sac-bootstrap-gate.conf systemctl is-enabled mariadb.service php8.3-fpm.service nginx.service studip-firstboot.service studip-cron.timer

The web root is the Stud.IP public/ directory and nothing above it. config/config_local.inc.php (this VM's database password) lives above the web root. The secret configuration and the command-line tools are never reachable over HTTP. Only the named front controllers execute PHP, so the removed setup wizard and any other .php file are refused. Check the web root and probe the protected paths:

grep -E '^\s+root ' /etc/nginx/sites-available/studip for p in /config/config_local.inc.php /config/config.inc.php /install.php /cli/studip; do printf '%-32s HTTP %s\n' "$p" "$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1$p)" done

The per-instance database password is unique to this VM, and the real login form rejects root@studip/testing and every other common guess. Exactly one administrator account exists on a fresh instance. Run the credential round trip:

sudo bash /usr/local/sbin/studip-cred-roundtrip.sh

Stud.IP stores users, courses, enrollments, documents, forums and settings in the studip MariaDB database. Take a consistent dump at any time:

sudo mysqldump --single-transaction studip > <backup-dir>/studip-$(date +%F).sql

Restore into an empty database with mysql studip < your-dump.sql.

Keep the dump somewhere off the VM, for example in Azure Blob Storage. If you store uploaded documents on the VM, keep the contents of /usr/local/studip/data there too.

The OS receives unattended security updates automatically. To move to a newer Stud.IP release, follow these steps:

• Back up the database and the data/ tree.
• Deploy the new release tree.
• Run sudo -u www-data php cli/studip migrate to apply the database migrations.
• Clear the cache.

Always test on a copy first. See the Stud.IP UPDATE.md for the release-specific steps.