| title | Quickstart |
|---|---|
| description | Create and prepare your first supported LibOps site |
LibOps supports the same application templates in two operating models: run the Compose project on infrastructure you control, or use the managed platform. Start with the ownership model that matches your team; the downstream Git repository remains the reviewable source of truth in either case.
Ask LibOps to review whether the currently released managed capability set fits your institution. Managed hosting is not a self-service offer yet. Fork a supported Compose template and operate it on a laptop, campus server, VM, or supported cloud.Choose the application that meets the service need, then name the institutional owner for content, access, upgrades, backups, and incident decisions. Review Supported Applications for the current application-ownership model before adding local code.
For a managed Site, first request a managed-beta review. LibOps provides Dashboard access only after accepting a beta scope whose required integrations have passed their release gates. For a self-hosted Site, start with the matching downstream template and fork ownership guide.
For an accepted managed-beta engagement, the onboarding screen collects the organization name, a provider-verified GitHub account, the supported application template, VM size, and storage choice before checkout. After Stripe confirms payment, one durable provisioning operation creates the project, private managed repository, production Site, initial deployment, and IP allowlist. The progress screen reports that operation; closing the browser does not cancel it. If onboarding reports that setup needs support, do not submit another purchase or create duplicate resources—contact LibOps from the link on that screen.
Managed resources are organized as:
- Organization — the institution-level boundary for ownership and policy.
- Project — related Sites and configuration that share an application purpose.
- Site — one runtime environment, such as production, staging, or review.
The first managed onboarding flow creates or selects the Organization and then creates its Project and production Site. Existing customers can select an existing Organization and Project when adding another Site. Keep shared settings at the highest appropriate scope and use Site-level overrides only when one environment must differ. See Resource Hierarchy for membership, firewall, setting, and secret inheritance.
Self-hosted operators should establish the same environment boundaries in repository, DNS, credential, and backup naming even when they do not use the managed API.
The downstream repository owns application customizations, Compose configuration, and reviewed environment defaults. Do not edit a running container as a deployment mechanism.
- Managed first site: onboarding copies the selected template into a private LibOps-managed repository and resolves its default branch before creating the initial deployment. For a customer-owned repository, install the LibOps GitHub App with access to that repository before connecting it to a Site.
- Self-hosted: provision a supported runtime, persistent storage, DNS, and backups, then deploy the fork using the template contract. cloud-compose can provision supported VM-based environments.
Technical operators can add sitectl for consistent local and remote Compose contexts. Installation, exact command syntax, and application-plugin behavior are maintained in the canonical sitectl documentation, not duplicated here.
Keep a new Site private while staff validate it. Before launch:
- place passwords, keys, and tokens in the appropriate secret store rather than tracked environment files;
- grant the narrowest organization, project, or Site role each person needs;
- restrict administrative access and expose public web traffic only when the production Site is ready;
- verify backups and perform an application-aware restore test;
- review the Site in a non-production environment and merge the approved repository change;
- follow Getting a Site Ready to Publish for DNS, firewall, email, and launch checks.
You can always work through a normal branch and GitHub pull request. In an approved managed-beta deployment where LibOps has enabled the Task Agent for the exact release, open the ready Site in the Dashboard, select Open Task Agent, confirm the Organization, Project, and Site context, and describe one scoped change. Review both the resulting preview and pull request before merging. See the Task Agent workflow for its current availability gates and review boundary.
Install or upgrade the core command and application plugins as a compatible set. Use the maintained authentication, resource, access-control, domain, and runtime command reference. Find application-aware creation, lifecycle, migration, and maintenance behavior. Review host, storage, secrets, upgrades, rollback, and recovery responsibilities. Need help choosing an operating model or preparing a production launch? [Contact LibOps](mailto:info@libops.io).