Container Scripts
Container scripts
What a ct/<app>.sh script is, how it is run, and what it does on the host and inside the container.
Every application has a container script at ct/<app>.sh in
ProxmoxVE. It is the
only file a user runs. The same file is used for three things:
| Where it runs | What happens |
|---|---|
| On a Proxmox VE or Incus host | Checks the host, shows the install menu, creates the container, runs install/<app>-install.sh inside it |
Inside a container it created (through the update command) | Runs the script's own update_script function and exits |
| On the website | The header comment and the var_* lines are what the script page and the command generator are built around |
Running one
On the Proxmox VE host, as root:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/gotify.sh)"This opens the menu (Default Install, Advanced Install, User Defaults,
App Defaults for <app> when a saved file exists, Settings). To skip the menu,
name the mode. Without mode= the menu opens even when every other value is set:
mode=default var_ram=1024 var_disk=4 \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/gotify.sh)"Inside the finished container, the same script is what update runs. See
Updates.
The shape of a script
A container script is short because it only declares the application. Everything else comes from the engine, which the second and third line load:
#!/usr/bin/env bash
_cs_boot="${COMMUNITY_SCRIPTS_CORE_DIR:-$(dirname "${BASH_SOURCE[0]}")/../../core}/core/build.func"
source "$_cs_boot" 2>/dev/null || source <(curl -fsSL "${COMMUNITY_SCRIPTS_CORE_URL:-https://raw.githubusercontent.com/community-scripts/core/main}/core/build.func")
APP="Gotify"
var_tags="${var_tags:-notification}"
var_cpu="${var_cpu:-1}"
var_ram="${var_ram:-512}"
var_disk="${var_disk:-2}"
var_os="${var_os:-debian}"
var_version="${var_version:-13}"
var_arm64="${var_arm64:-yes}"
var_unprivileged="${var_unprivileged:-1}"
header_info "$APP"
variables
color
catch_errors
function update_script() {
# runs inside the container
exit
}
start
build_container
description| Part | Purpose |
|---|---|
| Loader lines | Source core/build.func from a local checkout or from GitHub |
APP and var_* | The application's name, tags, resources, base OS and container type |
header_info, variables, color, catch_errors | Banner, derived names and log paths, colours, error traps |
update_script | The update logic, run inside an existing container |
start | On a host: checks and menu. In a container: the update path, which ends the script |
build_container | Creates and starts the container, then runs the install script in it |
description | Writes the container notes and reports the run as finished |
Where to go next
- Anatomy of a container script goes through every line with real scripts.
- Install scripts covers the file
build_containerruns inside the container. - What
build_containerdoes on the host covers templates,pct create, features, passthrough and failure handling. - Troubleshooting lists the errors users hit most.