@serve.zone/appstore
This repository is the curated App Store index consumed by serve.zone runtimes. It publishes @serve.zone/appstore, a small TypeScript client that parses and resolves App Store metadata, linked servezone.appstore.json manifests, and Docker digest-tracked image sources.
Issue Reporting and Security
For reporting bugs, issues, or security vulnerabilities, please visit community.foss.global/. This is the central community hub for all issue reporting. Developers who sign and comply with our contribution agreement and go through identification can also get a code.foss.global/ account to submit Pull Requests directly.
Install
pnpm add @serve.zone/appstore
The client speaks the @serve.zone/interfaces 32 App Store contracts. The storage feature IDs, delivery formats, and index and manifest shapes documented below are the 32 spellings; nothing older is accepted under a second name.
What Is In This Repo
| File or directory | Purpose |
|---|---|
appstore.json |
Top-level App Store index with app IDs, display names, descriptions, categories, icons, latest versions, and tags. |
apps/<app>/app.json |
App-specific metadata, maintained version list, and optional links. |
apps/<app>/versions/<version>/config.json |
Deployable version definition: image, internal port, environment variables, platform requirements, and compatibility metadata. |
ts_client/ |
Published @serve.zone/appstore parser and resolver client. |
source.type=repoManifest |
Optional link to a servezone.appstore.json file owned by the upstream app repo. |
Changes are reviewed by reading the JSON data, running the client tests, and testing affected templates in Onebox or Cloudly.
Current App Store
The App Store currently lists 21 app templates.
| App ID | Name | App Store category | Image | Port |
|---|---|---|---|---|
adminer |
Adminer | Dev Tools | adminer:latest |
8080 |
cloudly |
Cloudly | Dev Tools | code.foss.global/serve.zone/cloudly@sha256:056553fec412094701764197574b45096cc5c0c81e863d7ee873f4cf10ab45f6 |
3000 |
ghost |
Ghost | CMS | ghost:latest |
2368 |
gitea |
Gitea | Dev Tools | gitea/gitea:latest |
3000 |
gitops |
GitOps | Dev Tools | code.foss.global/serve.zone/gitops:2.13.0 |
3000 |
grafana |
Grafana | Monitoring | grafana/grafana:latest |
3000 |
mariadb |
MariaDB | Database | mariadb:latest |
3306 |
mattermost |
Mattermost | Communication | mattermost/mattermost-team-edition:latest |
8065 |
n8n |
N8N | Automation | n8nio/n8n:latest |
5678 |
nextcloud |
Nextcloud | Storage | nextcloud:latest |
80 |
nginx |
Nginx | Web Server | nginx:alpine |
80 |
openbao |
OpenBao | Security | openbao/openbao:2.6.0 |
8200 |
plausible |
Plausible Analytics | Analytics | plausible/analytics:latest |
8000 |
portainer |
Portainer | Dev Tools | portainer/portainer-ce:latest |
9000 |
postgres |
PostgreSQL | Database | postgres:16-alpine |
5432 |
valkey |
Valkey | Database | valkey/valkey:9.1.0-alpine |
6379 |
rustdesk-server |
RustDesk Server | Remote Access | rustdesk/rustdesk-server-s6:latest |
21116 |
siprouter |
SIP Router | Communication | code.foss.global/serve.zone/siprouter:1.28.0 |
3060 |
uptime-kuma |
Uptime Kuma | Monitoring | louislam/uptime-kuma:latest |
3001 |
vaultwarden |
Vaultwarden | Security | vaultwarden/server:latest |
80 |
wordpress |
WordPress | CMS | wordpress:latest |
80 |
Platform Requirements
Some templates ask Onebox to provision local platform services and inject connection variables into the workload.
platformRequirements accepts the optional booleans mongodb, s3, clickhouse, valkey, mariadb, and mail. Unknown keys and non-boolean values fail validation.
mail: true requests a platform mail binding. Onebox provisions a CoreMail binding for the app and injects MAIL_COREMAIL_URL, MAIL_COREMAIL_BINDING_ID, MAIL_COREMAIL_CREDENTIAL_ID, MAIL_COREMAIL_CREDENTIAL_VERSION, MAIL_COREMAIL_CREDENTIAL_SECRET, MAIL_FROM, SMTP_HOST, SMTP_PORT, SMTP_TLS_MODE, SMTP_USERNAME, and SMTP_PASSWORD. Those identities are platform-owned, so a template must not declare them itself.
| App ID | Requirements | Notes |
|---|---|---|
cloudly |
MongoDB, S3 | Version 1.1.10 pins Cloudly 26.0.1 and requires Onebox 8.3.3. It adds human and node credential authority and generation-bound human API and registry sessions while preserving the 1.1.9 runtime contract, existing user and storage identities, and OIDC bindings. Existing human sessions must sign in again. Rotate existing passwords through Cloudly credential administration; updating the bootstrap environment alone does not rotate them. Both the existing Secrets v2 keyring and operator-approved WorkloadInit authority are required encrypted inputs delivered as separate root-owned 0400 files; the public environment contains only their fixed paths. Complete cutover retirement and verify a fresh restorable checkpoint before upgrading. Rollback remains full-restore-only. |
ghost |
MariaDB | Uses MySQL-style database__connection__* environment variables. |
gitea |
MariaDB | Uses Gitea database environment variables with ${MARIADB_*} placeholders. |
nextcloud |
MariaDB, Valkey | Uses MySQL-compatible database variables. Valkey is declared as a platform requirement. |
plausible |
ClickHouse | Declares ClickHouse as a platform requirement. |
siprouter |
MongoDB, S3 | Uses SmartData state and object storage for telephony-related runtime data. |
wordpress |
MariaDB | Uses standard WordPress database environment variables. |
Standalone templates such as nginx, adminer, valkey, portainer, mattermost, n8n, uptime-kuma, and vaultwarden currently define only image and port unless their version config adds explicit environment variables. rustdesk-server uses the official all-in-one s6 image and requires RELAY to advertise the public relay endpoint; RustDesk clients also require firewall access to TCP 21115, TCP/UDP 21116, TCP 21117, and optional web-client TCP 21118/21119.
Template Schema In Practice
Version configs use a small, pragmatic schema understood by serve.zone runtimes:
{
"image": "container/image:tag",
"port": 8080,
"envVars": [
{
"key": "ENV_NAME",
"value": "${PLACEHOLDER_OR_DEFAULT}",
"description": "Shown in the App Store UI",
"required": true
},
{
"key": "APP_TOKEN",
"description": "Generated application token",
"required": true,
"secret": true,
"delivery": {
"type": "launcher-environment",
"variableName": "APP_TOKEN",
"uid": 1000,
"gid": 1000,
"mode": 256
},
"generate": {
"encoding": "hex",
"bytes": 32
}
}
],
"platformRequirements": {
"mariadb": true,
"mongodb": true,
"s3": true,
"valkey": true,
"clickhouse": true,
"mail": true
},
"minOneboxVersion": "1.24.2"
}
Secret declarations never contain values. Each declares exactly one file or
launcher-environment delivery destination and may request bounded hex or
base64url generation. Public environment keys may use the mixed-case forms
required by upstream images; secret and platform-owned environment identities
remain uppercase canonical keys.
platformRequirements.s3: true and volumes are legacy inputs. The resolver
normalizes them deterministically for existing templates, but new templates use
portable, template-local storageClasses and stable named storageRequests.
Legacy platformRequirements.s3: true cannot coexist with an explicit
objectStorage request. Legacy volume objects may retain name, mountPath,
readOnly, and backup; source, driver, and options fail validation
because they cannot be normalized portably.
Portable Storage Requests
Filesystem mounts and managed object-storage resources are different request kinds in the same portable contract. An app can request both, including more than one isolated object-storage binding:
{
"storageClasses": {
"databaseFast": {
"kind": "filesystem",
"purpose": "database",
"required": {
"performanceTier": "highIops",
"durability": "persistent",
"hardQuota": true,
"snapshots": "native",
"backup": true,
"encryptedInTransit": true
}
},
"backupCapacity": {
"kind": "objectStorage",
"purpose": "backup",
"required": {
"performanceTier": "capacity",
"durability": "persistent",
"hardQuota": true,
"backup": true,
"encryptedInTransit": true
}
}
},
"storageRequests": [
{
"id": "database-data",
"kind": "filesystem",
"storageClass": "databaseFast",
"mountPath": "/var/lib/example",
"accessMode": "ReadWriteOnce",
"capacity": { "request": "20GiB", "limit": "40GiB" },
"reclaimPolicy": "retain",
"protection": {
"backup": "required",
"snapshots": "native",
"consistency": "crashConsistent"
}
},
{
"id": "backup-archive",
"kind": "objectStorage",
"storageClass": "backupCapacity",
"accessMode": "readWrite",
"capacity": { "request": "100GiB", "limit": "1TiB" },
"reclaimPolicy": "retain",
"delivery": {
"type": "file",
"targetPath": "/run/secrets/backup-archive.json",
"format": "servezone-object-storage",
"uid": 1000,
"gid": 1000,
"mode": 256
},
"protection": {
"backup": "required",
"versioning": "required",
"retentionDays": 30
}
},
{
"id": "registry-capacity",
"kind": "objectStorage",
"storageClass": "backupCapacity",
"accessMode": "readWrite",
"reclaimPolicy": "retain",
"delivery": {
"type": "launcher-environment",
"keys": {
"endpoint": "REGISTRY_S3_ENDPOINT",
"bucket": "REGISTRY_S3_BUCKET",
"region": "REGISTRY_S3_REGION",
"accessKeyId": "REGISTRY_S3_ACCESS_KEY_ID",
"secretAccessKey": "REGISTRY_S3_SECRET_ACCESS_KEY"
}
}
}
],
"requiresFeatures": [
"storage.bindings",
"storage.filesystem",
"storage.object-storage",
"storage.object-storage.file"
]
}
Capacity values are positive integers followed by KiB, MiB, GiB, or
TiB; the amount must stay within the safe integer range. A limit requires
storageClass.required.hardQuota: true. For explicit
requests, delivery environment keys and file delivery paths must be unique across
the app config; provider credential values never belong in an App Store manifest.
protection is optional and states what a request needs beyond the storage
itself. A filesystem request may declare backup: "required", snapshots
(portable or native), and consistency (crashConsistent or
applicationConsistent); an object-storage request may declare
backup: "required", versioning: "required", and retentionDays (1 to
36500). A required backup or snapshots mode must also be declared by the
request's storage class. Omit protection to request no protection — a
declared protection must request at least one requirement, and
"protection": {} is refused, because an empty object states nothing a
fulfillment adapter can act on and names a request the platform storage
contract rejects.
The full version config and every storage object are exact-key validated.
Classes express portable policy only. Provider addresses, protocols,
identities, host paths, drivers, and driver options are rejected instead of
being passed through. Unknown storage.* feature IDs also fail closed. Request
IDs are stable across upgrades, restores, and migrations.
Before provisioning, a runtime must advertise its supported feature IDs and call the resolver's fail-closed normalization entry point:
const normalizedStorage = resolver.normalizeStorageConfig(config, {
supportedFeatures: capabilityAdvertisement.featureIds,
});
The package also exports the pure validateAppStoreStorageConfig() and
normalizeAppStoreStorageConfig() functions, parseStorageCapacityQuantity(),
and the normalized storage handoff types. Structural validation is useful for
catalog ingestion; only normalization with a target's supportedFeatures is a
valid pre-fulfillment gate.
The result contains canonical storageClasses, storageRequests,
requestOrigins, and requiredFeatureIds. requestOrigins marks explicit,
legacy-volume, and legacy-S3 requests so fulfillment adapters can preserve old
delivery behavior without weakening the new contract. Legacy S3 normalization
uses the servezone-platform-s3 delivery profile; adapters keep
the established S3/AWS environment aliases for that profile. Those
binding-provided values deterministically replace same-key legacy template
environment values. Legacy inputs do not claim new feature support, while every
explicit request fails before provisioning if a derived storage feature is
unavailable.
Environment variable keys must start with a letter or underscore and may contain letters, numbers, and underscores. Mixed-case keys are supported because some upstream images, including Ghost and Gitea, require lowercase nested configuration segments such as database__connection__host or GITEA__database__HOST.
Linked app manifests use the same runtime schema and let the upstream app repo own its install and upgrade metadata:
{
"app": {
"id": "cloudly",
"name": "Cloudly",
"description": "Multi-node serve.zone control plane.",
"category": "Dev Tools"
},
"latestVersion": "latest",
"source": {
"type": "dockerImage",
"image": "code.foss.global/serve.zone/cloudly:latest",
"tracking": "digest"
},
"runtime": {
"image": "code.foss.global/serve.zone/cloudly:latest",
"port": 3000
}
}
When tracking is digest, Onebox resolves the Docker manifest digest and treats digest changes as App Store upgrades while keeping the image reference simple for deployment.
Neither the index nor a linked manifest states a schema version. Published documents that still carry a schemaVersion member are read unchanged — the readers ignore it — so a catalog can be republished without the member at any time.
Client Usage
import { AppStoreResolver } from '@serve.zone/appstore';
const resolver = new AppStoreResolver();
const appStore = await resolver.getAppStoreIndex();
const cloudly = await resolver.getAppMeta('cloudly');
const config = await resolver.getAppVersionConfig('cloudly', cloudly.latestVersion);
The resolver defaults to the App Store data bundled in the published @serve.zone/appstore package. Tests and explicit remote consumers can inject a custom fetch implementation and base URL. Remote operations default to a 30-second timeout, configurable with a positive-integer requestTimeoutMs.
Catalog resolution fails closed when index and app metadata IDs or latest versions disagree, when metadata latest is absent from its version list, or when an all-semver list does not select its highest semantic value. Repo manifests with multiple non-semver versions require explicit latest or channel intent; array position never determines latest.
Only include keys that are actually needed by a template. For example, nginx is currently just:
{
"image": "nginx:alpine",
"port": 80
}
Working With Templates
- Keep
appstore.json,apps/<app>/app.json, and each version config in sync when adding or changing an app. - Prefer package-published App Store data for runtime consumers. Use
source.type=repoManifestonly when the linked manifest is intentionally reachable from the runtime environment, or pre-resolve it before publishing an App Store package. - Prefer explicit environment variable descriptions because Onebox surfaces them to users during installation.
- Use platform placeholders such as
${MARIADB_HOST},${MARIADB_PORT},${MARIADB_DATABASE},${MARIADB_USER},${MARIADB_PASSWORD},${MONGODB_URI},${S3_BUCKET},${S3_ACCESS_KEY},${S3_SECRET_KEY},${MAIL_FROM},${SMTP_HOST},${SMTP_PORT},${SMTP_USERNAME}, and${SMTP_PASSWORD}only when the matching platform service is declared. - Use named
objectStoragerequests instead ofplatformRequirements.s3in new templates, with a distinct delivery destination for every binding. - Use named
filesystemrequests instead ofvolumesin new templates. Never put provider, host-mount, protocol, identity, driver, or driver-option details in portable manifests. - Keep template images boring and operationally safe unless there is a reason to pin a more specific upstream tag.
- Validate non-trivial templates by installing them through Onebox instead of only checking JSON syntax.
Project Map
appstore/
├── appstore.json
├── ts_client/
└── apps/
├── cloudly/
│ ├── app.json
│ └── versions/<version>/config.json
└── ...
License and Legal Information
This repository contains open-source code licensed under the MIT License. A copy of the license can be found in the license file.
Please note: The MIT License does not grant permission to use the trade names, trademarks, service marks, or product names of the project, except as required for reasonable and customary use in describing the origin of the work and reproducing the content of the NOTICE file.
Trademarks
This project is owned and maintained by Task Venture Capital GmbH. The names and logos associated with Task Venture Capital GmbH and any related products or services are trademarks of Task Venture Capital GmbH or third parties, and are not included within the scope of the MIT license granted herein.
Use of these trademarks must comply with Task Venture Capital GmbH's Trademark Guidelines or the guidelines of the respective third-party owners, and any usage must be approved in writing. Third-party trademarks used herein are the property of their respective owners and used only in a descriptive manner, e.g. for an implementation of an API or similar.
Company Information
Task Venture Capital GmbH
Registered at District Court Bremen HRB 35230 HB, Germany
For any legal inquiries or further information, please contact us via email at hello@task.vc.
By using this repository, you acknowledge that you have read this section, agree to comply with its terms, and understand that the licensing of the code does not imply endorsement by Task Venture Capital GmbH of any derivative works.