# DeployVera — technical reference Last reviewed: 2026-10-30 # DeployVera technical documentation Verify scope, limits and data behaviour before moving an application. Last reviewed: 2026-10-30 ## What the service price covers A web application or HTTP API uses an application slot and the service’s shared CPU, RAM and disk pool. API hosting does not require a separate product. Managed PostgreSQL is in beta. It attaches to an active container service, has a separate database quota, and shares that service’s resources. Database quota and application quota are different. Use the live catalog for current limits, prices and purchase terms. ## Idle sleep Current deployments run Docker containers. There is no automatic traffic-based idle sleep or scale-to-zero feature. User stops, service suspension, maintenance and application failures are separate conditions. ## Data across redeployments The application’s writable container layer is not persistent storage. Data on a correctly mounted persistent volume and in a separate managed database is independent of a normal application redeployment. Deletion, data migration and database recreation are different operations. ## Backups and restoration Platform operations include daily backups and encrypted off-site copies. The customer panel does not currently provide per-database self-service backup downloads and one-click restoration. Confirm database-specific backup coverage and restoration through support. Sources: https://api.deployvera.com/api/plans · https://deployvera.com/docker · https://deployvera.com/help --- # Deploy your first application From a Git repository to a running API or website. Last reviewed: 2026-10-30 ## Prepare the repository Connect GitHub or GitLab, or use a public HTTPS repository. Gitea is visible only in Enelsa mode or for an account explicitly granted connector access. Choose the branch, Dockerfile or automatic build method, and listening port. Bind the HTTP server to `0.0.0.0`; a process listening only on localhost cannot be reached by the application proxy. ## Create it in the panel - Select an active service and check its available application slots. - Choose the repository and branch. Automatic deployment follows pushes to that connected branch. - Configure the build method, port and required environment variables. - Start deployment, inspect build logs, then verify runtime status. ## Python API example Set the application port to 8000 for this example. Change the module path to match your project. ``` FROM python:3.13-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"] ``` ## Verify the live revision Runtime state and commit freshness are separate. Compare the live SHA with the head of the connected branch. A failed or cancelled build does not make the previous running version a deployment of the new commit. Sources: https://api.deployvera.com/api/plans · https://deployvera.com/docker · https://deployvera.com/help --- # Plans and PostgreSQL Application slots, shared resources and database beta scope. Last reviewed: 2026-10-30 ## Service resources are shared Applications and attached managed databases share the service’s CPU, RAM and disk limits. Do not assume each application receives the whole plan’s resources independently. The permanent free plan is not a trial. Each account can have only one non-terminated free service. Its current limits are 1 vCPU, 2 GB RAM, 10 GB disk and one application. Use the live catalog and pre-payment invoice for currency, tax and campaign eligibility. ## Managed PostgreSQL PostgreSQL can be created as a beta managed database attached to a container service. The public installation’s default quota is three managed databases per service; the limit reported for the particular service is authoritative. Creating a database does not create a separate database subscription. Get the private endpoint and credentials from the panel. Connect the application and database through the service’s private network. Set DATABASE_URL in the actual application runtime; keep it out of the repository. ## API and database are separate resources An API application consumes one application slot. A managed database uses the separate database quota. Installing a database inside an application image is a different arrangement with different resource, storage and backup responsibilities. Sources: https://api.deployvera.com/api/plans · https://deployvera.com/docker · https://deployvera.com/help --- # Persistent data and redeployment Know which data belongs to the image and which belongs to storage. Last reviewed: 2026-10-30 ## Three kinds of storage - Repository files: versioned content copied into the image during build. - Writable container layer: runtime files that may disappear when the container is replaced. - Persistent volume or database: image-independent data retained across normal redeployment. ## Use the real persistent path Verify the actual mount path for uploads, SQLite files or generated models. Calling a folder storage does not make it persistent. A mounted volume can hide files copied into the same image directory by a new commit. Check that an import file is actually present in the running container. ## PostgreSQL persistence A separate managed PostgreSQL data volume is independent of the application container. Redeploying only the application does not reset that database. Deleting a database or service can delete data; deletion is not redeployment. ## Schema changes Deploying code does not automatically make a database schema compatible. Manage application migrations and rollback compatibility explicitly. Persistent storage and a one-off seed/import step are separate concerns. Sources: https://api.deployvera.com/api/plans · https://deployvera.com/docker · https://deployvera.com/help --- # Backups, exports and restoration Understand the scope of operational platform backups. Last reviewed: 2026-10-30 ## Operational backups Platform operations include scheduled local database backups and encrypted off-site copies. Integrity checks and restore drills are part of the operational procedure. That mechanism alone does not prove every customer database can be restored at any moment. Verify the latest evidence, coverage of that database, and a relevant restoration test separately. ## Current customer-panel scope A self-service per-database download and one-click restore workflow is not currently published. Open a support ticket for export or operator-assisted restoration. Confirm retention, RPO and RTO in writing. ## Independent logical exports PostgreSQL tools such as pg_dump and pg_restore can be used with appropriate credentials and an available network path. Do not assume a private endpoint is directly reachable from the internet. Define an independent backup policy for critical application data. An image, commit or successful deployment record is not a database backup. ## Include in a restoration request - Which database and service? - Which backup date and target point? - Overwrite existing data or restore into a separate database? - How will schema compatibility and restored data be verified? Sources: https://api.deployvera.com/api/plans · https://deployvera.com/docker · https://deployvera.com/help --- # One-off commands and project settings Use the same runtime configuration as the running application. Last reviewed: 2026-10-30 ## Project settings groups - Access and security: project visitor password and public/private exposure. - Deployment settings: repository, branch, service, domains and deployment actions. - Technical settings: runtime version, port, build/start commands and environment variables. ## One-off imports and migrations Putting an import in the start command can run it on every restart. Verify whether a one-off script is idempotent and targets the intended database. The following command is for a server operator. Do not assume customer-panel users have host Docker or SSH access; request operator assistance if no shell is available. ``` docker exec -w /app \ python scripts/import_data.py /data/import.json ``` ## The runtime environment matters docker exec does not automatically inherit variables exported by an entrypoint only to its own child process. In particular, verify DATABASE_URL matches the running application’s connection. Use the existing secure runtime configuration rather than putting passwords in shell history or chat. ## When must it run again? If the same persistent database is retained, a completed one-off import does not need to run on every deploy. A new dataset or recreated database may require another import. Determine repeat behaviour from the script’s insert/upsert logic, not its filename. Sources: https://api.deployvera.com/api/plans · https://deployvera.com/docker · https://deployvera.com/help --- # Reference for AI assistants Public readable sources and the limits of what they establish. Last reviewed: 2026-10-30 ## Source priority - Current prices and plan limits: the live /api/plans catalog. - Feature scope: these documents and platform.json. - A specific project’s state: the owner’s authorized panel or authenticated API response. - Current reachability: the status page and the application’s health endpoint. ## Machine-readable versions Every article has a Markdown URL. /docs/platform.json describes capability scope, /docs/llms.txt indexes articles, and /llms-full.txt contains all English technical articles. Content is rendered on the server and needs neither authentication nor JavaScript to read. ## API scope The public product catalog is available at GET https://api.deployvera.com/api/plans. Hosting an API application does not grant unrestricted access to DeployVera’s management API. Customer resources require authentication and ownership checks. Do not invent unpublished endpoints, a personal access-token flow or an MCP server. Administrator permissions differ from customer permissions. ## Keep these facts separate Do not describe a beta feature as generally available or guaranteed. A running application does not prove it runs the newest commit or has a verified backup. Distinguish container files, persistent volumes and managed databases. Sources: https://api.deployvera.com/api/plans · https://deployvera.com/docker · https://deployvera.com/help