ISPConfig

Search for ISPConfig in Marketplace, select the SecureAnyCloud publisher, and click Create.

Configure the Network Security Group to allow TCP 22 and TCP 8080 from your management network only. Do not expose the panel to the whole internet until you have completed Step 9 and put a trusted certificate in front of it.

RG="ispconfig-prod"; LOCATION="eastus"; VM_NAME="ispconfig" IMAGE_URN="sac1647283583153:ispconfig-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:ispconfig-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

On first boot, the VM generates every secret it needs. ispconfig-firstboot.service runs once, before Apache starts serving the panel. It does the following:

• Rotates the MariaDB root password and the panel database password, rewriting ISPConfig's configuration files in lock step.
• Rotates the panel administrator password and the remote API password.
• Regenerates the self-signed panel TLS certificate with the VM's address.
• Writes everything to /root/ispconfig-credentials.txt and drops a sentinel so it never runs again.

Wait about thirty seconds after the VM reports running. Then connect over SSH and confirm the stack.

Connect over SSH:

ssh azureuser@<vm-ip>

Confirm the database and the panel are up:

systemctl is-active mariadb apache2 curl -ks -o /dev/null -w 'panel HTTP %{http_code}\n' https://127.0.0.1:8080/login/

MariaDB and Apache both report active, and the panel returns HTTP 200.

Confirm the component versions:

grep -oE "ISPC_APP_VERSION', *'[^']+'" /usr/local/ispconfig/interface/lib/config.inc.php apache2 -v | head -1 php -v | head -1 mariadb --version

Confirm which ports are listening. Port 8080 is the control panel, and ports 80 and 443 serve the web sites you host:

ss -tlnp | grep -E ':(8080|80|443) ' | awk '{print $1, $4}' | sort -u

Read your per-VM credentials. This file is mode 0600 and readable only by root:

sudo cat /root/ispconfig-credentials.txt

The panel username is admin. The password is the ispconfig.admin.pass value in that file, and it is unique to your VM.

Browse to https://<vm-ip>:8080/ and accept the self-signed certificate warning. Step 9 replaces the certificate with a trusted one.

Sign in with the username admin and the ispconfig.admin.pass password from Step 4. You land on the ISPConfig dashboard, with the Client, Sites, Monitor, Tools and System modules across the top and the available modules listed below.

The upstream default is rejected. ISPConfig normally ships with admin / admin, but this image does not. From the shell, you can confirm that your per-VM password works and that both the default and a blank password are refused:

sudo python3 /usr/local/sbin/ispconfig-panel-check.py && echo "per-VM password works; admin/admin and blank are rejected"

Hosting in ISPConfig is organized around clients. Open the Client module and click Add new client to create a hosting customer. You can also create clients from the shell through the remote API in Step 8.

Open the Sites module and click Add new website. Choose the PHP handler and version, and assign the site to a client.

ISPConfig provisions the Apache virtual host and writes the Apache configuration and the document root for you.

ISPConfig exposes a JSON-RPC remote API at /remote/json.php. The image ships a remote user (sac_api). Its password is generated per VM and stored alongside the admin password in /root/ispconfig-credentials.txt.

The following commands log in, create a client, read it back and delete it, which proves the API end to end:

API_USER=$(sudo grep '^ispconfig.api.user=' /root/ispconfig-credentials.txt | cut -d= -f2)
API_PASS=$(sudo grep '^ispconfig.api.pass=' /root/ispconfig-credentials.txt | cut -d= -f2)
python3 - "$API_USER" "$API_PASS" <<'PY' import sys, ssl, json, urllib.request, secrets user, pw = sys.argv[1], sys.argv[2] base = "https://127.0.0.1:8080" ctx = ssl.create_default_context(); ctx.check_hostname = False; ctx.verify_mode = ssl.CERT_NONE def call(fn, payload): req = urllib.request.Request(base + "/remote/json.php?" + fn, data=json.dumps(payload).encode(), headers={"Content-Type": "application/json"}) o = json.loads(urllib.request.urlopen(req, timeout=30, context=ctx).read().decode()) assert o.get("code") == "ok", "%s failed: %s" % (fn, o.get("message")) return o.get("response") sid = call("login", {"username": user, "password": pw}) name = "demo" + secrets.token_hex(3) cid = int(call("client_add", {"session_id": sid, "reseller_id": 0, "params": { "company_name": "Demo Hosting", "contact_name": "Demo", "username": name, "password": secrets.token_hex(12), "email": name + "@example.com", "language": "en", "usertheme": "default", "country": "US", "web_php_options": "no,fast-cgi,php-fpm", "ssh_chroot": "no"}})) got = call("client_get", {"session_id": sid, "client_id": cid}) print("created + read back client id", cid, "username", (got[0] if isinstance(got, list) else got)["username"]) call("client_delete", {"session_id": sid, "client_id": cid}) call("logout", {"session_id": sid}) print("API round-trip OK") PY

The full remote API documentation is at docs.ispconfig.org.

The panel ships with a per-VM self-signed certificate, so browsers warn on first use. Point a DNS name at the VM, then obtain a Let's Encrypt certificate and place it where ISPConfig serves the panel:

sudo apt-get install -y certbot
sudo certbot certonly --standalone -d panel.your-domain.example
sudo cp /etc/letsencrypt/live/panel.your-domain.example/fullchain.pem /usr/local/ispconfig/interface/ssl/ispserver.crt
sudo cp /etc/letsencrypt/live/panel.your-domain.example/privkey.pem /usr/local/ispconfig/interface/ssl/ispserver.key
sudo cat /usr/local/ispconfig/interface/ssl/ispserver.key /usr/local/ispconfig/interface/ssl/ispserver.crt > /usr/local/ispconfig/interface/ssl/ispserver.pem
sudo systemctl restart apache2

Restrict the Network Security Group so that port 8080 is reachable only from the networks that manage the server.

This image is focused on web, database and panel management, so the mail and DNS server modules are not installed. To add them, choose one of two routes:

• Re-run the ISPConfig autoinstaller without the --no-mail or --no-dns switch, following the upstream documentation at docs.ispconfig.org.
• Install and configure Postfix, Dovecot and BIND, then enable their ISPConfig server modules under System.

The panel lives under /usr/local/ispconfig. Its interface configuration is in /usr/local/ispconfig/interface/lib/config.inc.php, and hosted site data is under /var/www.

ISPConfig runs its periodic work from a cron entry that calls /usr/local/ispconfig/server/server.sh every minute. Leave it in place.

The operating system, Apache, PHP and MariaDB packages continue to receive security updates through unattended upgrades. ISPConfig itself is pinned to the release this image shipped. Follow the upstream release notes when you choose to move to a newer version.

• Restrict the Network Security Group so TCP 22 and TCP 8080 are reachable only from your management networks. Put a trusted certificate in front of the panel before wider exposure (Step 9).
• Treat /root/ispconfig-credentials.txt as a one-time handover. Record the values in your password manager, then remove the file.
• After first sign-in, change the administrator password from the generated one under Tools -> Password and Language. Create named administrator accounts rather than sharing admin.
• Keep MariaDB bound to the loopback interface. Nothing outside the VM needs to reach it directly.
• If you do not use the API, rotate the remote API user's password or disable the remote user under System -> Remote Users.

ISPConfig is free and open source software, published under the BSD 3-Clause License. The upstream project documentation is at docs.ispconfig.org.

SecureAnyCloud builds and maintains this image. Support for the image, including deployment questions and security updates, is available 24/7 through the support channel listed on the Azure Marketplace offer page.

Deploy on Azure

Launch ISPConfig 3.3 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

• Open the product page in AWS Marketplace and choose Continue to Subscribe, then Continue to Configuration.
• Select the software version and your AWS Region, then choose Continue to Launch.
• Choose an instance type of m5.large or larger, your VPC subnet, the security group described above and your EC2 key pair.
• Launch the instance and wait for it to reach the running state with status checks passed.

First boot initialization takes a minute or two after the status checks pass. The panel does not answer until it has finished. This is deliberate.

Replace the AMI ID, key name, security group and subnet with your own values.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --security-group-ids <security-group-id> \
  --subnet-id <subnet-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ispconfig}]'

Every credential in this image is generated on the first boot of your instance and is unique to it. They live in a root-only file.

The next command lists the credential keys without printing any secret value. It is safe to run in a shared terminal or paste into a ticket:

sudo grep -oE '^[a-z.]+' /root/ispconfig-credentials.txt | sed 's/$/ = <value>/'

ispconfig.url = <value> ispconfig.admin.user = <value> ispconfig.admin.pass = <value> ispconfig.api.user = <value> ispconfig.api.pass = <value> ispconfig.db.root.pass = <value> ispconfig.db.ispconfig.user = <value> ispconfig.db.ispconfig.pass = <value>

The next block confirms that the rotation happened and that the file is locked down, again without revealing anything. It prints the panel URL, the length of the generated secrets, and the file's permissions and owner:

sudo grep '^ispconfig.url=' /root/ispconfig-credentials.txt
sudo awk -F= '/^ispconfig\.admin\.pass=/{print "admin password: " length($2) " characters generated for this instance"}' /root/ispconfig-credentials.txt
sudo awk -F= '/^ispconfig\.api\.pass=/{print "api password: " length($2) " characters generated for this instance"}' /root/ispconfig-credentials.txt
sudo stat -c '%n %a %U:%G' /root/ispconfig-credentials.txt

ispconfig.url=https://50.16.90.220:8080/ admin password: 28 characters generated for this instance api password: 28 characters generated for this instance /root/ispconfig-credentials.txt 600 root:root

To read the actual passwords, run sudo cat /root/ispconfig-credentials.txt on the instance. Copy them into your password manager and treat that file as the only record. The passwords are not recoverable from anywhere else, and SecureAnyCloud does not hold them.

All four units should report active. The ispconfig-firstboot unit is a one-shot unit that stays active after it completes, which tells you first boot has finished.

for s in mariadb.service apache2.service pure-ftpd-mysql.service ispconfig-firstboot.service; do printf '%-30s %s\n' "$s" "$(systemctl is-active "$s")" done

mariadb.service active apache2.service active pure-ftpd-mysql.service active ispconfig-firstboot.service active

The panel answers on port 8080 with a redirect to the sign-in form:

curl -sk -o /dev/null -w 'panel login page: HTTP %{http_code}\n' --max-time 15 https://127.0.0.1:8080/

panel login page: HTTP 302

The image also ships a login round-trip checker. It proves three things at once:

• The per-instance administrator password authenticates against the live panel.
• The upstream admin/admin default is rejected.
• A blank password is rejected.

It prints OK and exits 0 only when all three hold.

sudo python3 /usr/local/sbin/ispconfig-panel-check.py

OK

Open the ispconfig.url value from Step 3 in a browser. For your instance, it is https://<public-ip>:8080/.

The panel serves a certificate generated for your instance on its first boot. Your browser warns on first use that the certificate is not from a public authority, so accept the warning to proceed. Step 9 shows how to replace it with a trusted certificate.

Sign in with the ispconfig.admin.user and ispconfig.admin.pass values from the credentials file. You land on the panel home page, which shows the available modules, upstream release news and live system metrics for the instance.

The seven modules across the top are the whole product:

• Client for clients and resellers.
• Sites for web sites, databases and FTP.
• Monitor for server state and logs.
• Tools for your own account.
• System for server configuration and panel users.

ISPConfig separates the people from the things they own. Create a client first, then create the web sites, databases and FTP accounts that belong to that client. Each client gets their own panel login and their own resource limits. This makes the panel usable for reseller and agency hosting, not just for one server's worth of sites.

To add a client, open Client, then Add Client. Fill in at least the company or contact name, a username and a password. On the Limits tab, cap how many web sites, databases and FTP accounts that client may create.

To add a web site, open Sites, then Website, then Add new website. Set the domain, choose the owning client, pick the PHP mode and set the disk quota. ISPConfig writes the Apache vhost, creates the document root under /var/www and provisions the site's system user for you.

To serve the site publicly, point your domain's DNS A record at the instance's public address. This image does not run a DNS server, so create that record wherever your domain is hosted.

Open Sites, then Databases. Create a database user first under Database Users. Then create a database under Databases and assign it to the owning client and the site it serves.

MariaDB is bound to loopback on this image. Databases are reachable from the instance itself and from the sites it hosts, but never directly from the internet. If you need remote database access, tunnel it over SSH rather than opening port 3306 in your security group.

ISPConfig exposes a JSON-RPC API at /remote/json.php on the panel port. This image provisions a dedicated API user for it, with a password generated on first boot.

The block below reads that credential into shell variables without echoing it. It then logs in, counts the clients the API can see, and logs out again.

API_USER=$(sudo grep '^ispconfig.api.user=' /root/ispconfig-credentials.txt | cut -d= -f2-)
API_PASS=$(sudo grep '^ispconfig.api.pass=' /root/ispconfig-credentials.txt | cut -d= -f2-)
SID=$(curl -sk --max-time 20 -H 'Content-Type: application/json' \
  -d "{\"username\":\"${API_USER}\",\"password\":\"${API_PASS}\"}" \
  'https://127.0.0.1:8080/remote/json.php?login' \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); print(d.get("response","") if d.get("code")=="ok" else "")') if [ -n "$SID" ]; then echo "remote API login: OK (session established)"; else echo "remote API login: FAILED"; exit 1; fi
COUNT=$(curl -sk --max-time 20 -H 'Content-Type: application/json' \
  -d "{\"session_id\":\"${SID}\",\"client_id\":0}" \
  'https://127.0.0.1:8080/remote/json.php?client_get_all' \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); r=d.get("response") or []; print(len(r) if isinstance(r,list) else 0)')
echo "clients visible through the API: ${COUNT}" curl -sk --max-time 20 -H 'Content-Type: application/json' -d "{\"session_id\":\"${SID}\"}" \
  'https://127.0.0.1:8080/remote/json.php?logout' >/dev/null
echo "remote API logout: OK"

remote API login: OK (session established) clients visible through the API: 0 remote API logout: OK

The API user ships with a scoped function whitelist covering client, web site and database management, which is what the provisioning calls above need. Widen or narrow it under System, then Remote Users.

The session ID is a live credential for as long as it is valid. Never log it or paste it anywhere.

Two exposure classes matter most on a public cloud hosting appliance: an open recursive DNS resolver and an open SMTP relay. This image ships neither, and the database is not reachable from off the instance. You can confirm all three yourself:

sudo ss -ltnH 'sport = :3306' | awk '{print "MariaDB listening on " $4}'
sudo ss -ltnH 'sport = :53' | awk '{print $4}' | grep -vE '^(127\.0\.0\.5[34]|127\.0\.0\.1|\[::1\])' | grep . || echo "no off-loopback DNS listener"
sudo ss -ltnH 'sport = :25' | awk '{print $4}' | grep -vE '^(127\.0\.0\.1|\[::1\])' | grep . || echo "no off-loopback SMTP listener"

MariaDB listening on 127.0.0.1:3306 no off-loopback DNS listener no off-loopback SMTP listener

The upstream admin/admin default is refused. The block below asserts that. A successful sign-in returns a 302 redirect to the dashboard, so any other response means the credentials were refused. The block exits non-zero if the default is ever accepted.

CODE=$(curl -sk -o /dev/null -w '%{http_code}' --max-time 20 \
  -d 's_mod=login' -d 's_pg=index' -d 'username=admin' -d 'password=admin' \
  https://127.0.0.1:8080/login/index.php) if [ "$CODE" = "302" ]; then echo "UNEXPECTED: the upstream default was accepted"; exit 1; fi echo "upstream default admin/admin refused (HTTP ${CODE}, not a 302 redirect) - correct"

upstream default admin/admin refused (HTTP 200, not a 302 redirect) - correct

The panel certificate is generated for your instance on its first boot, not baked into the image, so no two instances share a key:

sudo openssl x509 -in /usr/local/ispconfig/interface/ssl/ispserver.crt -noout -subject -dates

subject=CN = 50.16.90.220, O = sac notBefore=Jul 26 03:17:35 2026 GMT notAfter=Jul 23 03:17:35 2036 GMT

Apache also binds port 8081 for ISPConfig's built-in apps vhost. It is left out of the recommended security group, so it is not reachable from outside the instance. Under the recommended security group, the externally reachable ports are exactly 22, 80, 443 and 8080.

Hosted site content and the databases each live on their own EBS volume, mounted by filesystem UUID so the layout survives reboots and re-launches:

df -h --output=source,size,avail,target /var/www /var/lib/mysql

Filesystem Size Avail Mounted on /dev/nvme1n1 40G 38G /var/www /dev/nvme2n1 30G 28G /var/lib/mysql

To grow either tier, modify the EBS volume in the AWS console. Then extend the filesystem on the instance with sudo resize2fs against that device. Because the tiers are separate volumes, you can snapshot the databases on a different schedule from the site content.

The per-instance certificate is self-signed. That is fine for a panel that only your operators reach, but it produces a browser warning. To replace it with a publicly trusted certificate, point a DNS name at the instance and open TCP 80 so the ACME HTTP-01 challenge can complete. Then issue a certificate for that name:

sudo apt-get install -y certbot
sudo certbot certonly --standalone -d panel.<your-domain> --agree-tos -m admin@<your-domain> --non-interactive sudo cp /etc/letsencrypt/live/panel.<your-domain>/fullchain.pem /usr/local/ispconfig/interface/ssl/ispserver.crt
sudo cp /etc/letsencrypt/live/panel.<your-domain>/privkey.pem /usr/local/ispconfig/interface/ssl/ispserver.key
sudo cat /usr/local/ispconfig/interface/ssl/ispserver.key /usr/local/ispconfig/interface/ssl/ispserver.crt \
  | sudo tee /usr/local/ispconfig/interface/ssl/ispserver.pem >/dev/null
sudo chmod 600 /usr/local/ispconfig/interface/ssl/ispserver.key /usr/local/ispconfig/interface/ssl/ispserver.pem
sudo systemctl restart apache2

Sites you host through the panel get their own certificates independently. Once the site's DNS resolves to the instance, tick Let's Encrypt SSL on the site's SSL tab in the Sites module.

FTP is installed and running. PureFTPd listens on port 21 with a passive port range of 40110 to 40210. Those ports are not in the recommended security group. When you want FTP, add inbound TCP 21 and TCP 40110-40210 to it, then create accounts under Sites, then FTP-Accounts. Prefer SFTP over the SSH port where you can, because plain FTP sends credentials in clear text.

Mail and DNS are not managed by this image. To enable them, you install the service packages, re-run the ISPConfig installer so it writes the module configuration, unmask the resolver this image masks, and open the relevant ports.

Treat that as a considered change rather than a default. An internet-facing mail server needs reverse DNS, SPF, DKIM and relay restrictions to be useful and safe. An internet-facing name server needs recursion disabled for the world. Installing an IMAP server, for example, immediately opens ports 143 and 993 on every interface.

The following outline shows the shape of that change. Adapt it rather than pasting it as is:

sudo apt-get install -y postfix dovecot-imapd bind9
sudo systemctl unmask named
sudo /usr/local/ispconfig/server/scripts/update_from_dist.sh
# re-run, enabling the mail/DNS modules

If you take that route, size the instance up and review the ISPConfig documentation for the mail and DNS modules. Restrict the new ports in your security group before exposing either service to the internet.