Deployment and operations
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#overview.
Choose how your organization will run Travila: operate a complete self-hosted installation or use a Travila-managed dedicated single-tenant deployment. Choose AWS or Google Cloud (GCP), select a supported hosting region on that cloud and, when your application needs private systems, arrange an approved VPC peering connection. Complete the setup and recovery checks before moving real workloads.
Have an operating owner, required application capabilities, permitted model and software licenses, your approved cloud provider, data locations and network requirements. Use these to select a supported release and deployment configuration with clear installation, maintenance and recovery responsibilities.
Availability: Self-hosting, managed dedicated single tenancy, cloud-provider choice, customer-selected hosting regions and VPC peering are upcoming. AWS and Google Cloud are the initial cloud targets. This guide announces no currently available deployment profile, region list or recovery commitment. Confirm the qualified cloud, release, locations, connection options and operating terms before choosing a deployment.
Self-hosted capability is not an Enterprise-only entitlement. A managed dedicated deployment has its own agreed scope, pricing and operating responsibilities. Commercial plan selection and deployment readiness are separate decisions.
1. Choose the operating arrangement for your application
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#deployment-scope.
Start with the workloads, data and operating responsibilities that matter to your organization:
| Operating choice | Who runs the application |
|---|---|
| Customer-operated self-hosting | Your team installs and operates the complete supported release on infrastructure it controls, including upgrades, monitoring and recovery |
| Travila-managed dedicated single tenancy | Travila operates an agreed deployment reserved for your organization, with explicit customer responsibilities and support-access terms |
Infrastructure ownership and operating ownership are separate. Record both; owning a cloud account does not by itself establish who operates Travila there. Choose from the supported configurations and resolve an unsupported arrangement before proceeding.
| Decision | Record before selecting a deployment |
|---|---|
| Application scope | Required capabilities, users, traffic patterns, model workloads and expected storage growth |
| Hosting cloud | AWS or Google Cloud, the supported deployment configuration, account ownership and provider-specific costs |
| Operating ownership | Who installs, upgrades, monitors, responds to incidents, manages credentials and performs recovery |
| Data handling | Approved primary, backup and recovery locations, retention, exports, deletion and external integrations |
| Private connectivity | Applications to connect, traffic direction, supported network layout and responsibility for both ends |
| Dependencies | Required local components, optional hosted integrations and the effect of disabling each optional integration |
| Capacity and recovery | The tested workload, disruption assumptions, recovery procedure and any agreed recovery objectives |
| Release and support | Exact supported release/configuration, update responsibility, known limitations and agreed support channel |
The complete self-hosted offering lets you sign up, create a project and credentials, run an agent, use memory and files, receive events, evaluate results and manage usage limits without a mandatory hosted control service. Local model and embedding backends support operation without a hosted model account, subject to the models’ use terms. Release documentation identifies the supported configuration and any limits.
Payment networks, mobile push networks and customer-connected external systems still require their respective external services. When an integration is disabled, its status explains the unavailable action and the features that remain usable, such as in-app events or invoice records.
2. For managed hosting, reserve dedicated capacity
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#dedicated-deployment.
Choose managed dedicated single tenancy when your organization needs application compute and customer-data stores reserved for its use. Identify the organization and projects covered, required capacity and features, then review the allocation with Travila before accepting the offer.
The deployment record describes the dedicated scope for application execution, queues, caches, databases, files, secrets and backups. It also identifies any shared management, monitoring or support services, the information they receive and who may access it. Isolation between your organization's projects continues to apply within the dedicated deployment.
Confirm the allocation, capacity checks and access checks during handover. The agreed boundary prevents another organization from accessing your deployment or consuming its reserved capacity. The offering describes which resources are reserved; it does not imply dedicated physical hardware. Keep maintenance, backup, incident response and support-access responsibilities with the deployment record.
3. For managed hosting, choose an approved cloud
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#hosting-cloud.
Choose AWS or Google Cloud (GCP) for your managed dedicated deployment when your organization standardizes its infrastructure, operating expertise or purchasing commitments on that provider. Select the cloud first, then a supported region and deployment configuration on that cloud.
- Match your cloud requirements. Record the approved provider, required capabilities and network connections. Review the supported regions, capacity, backup and recovery options for that provider.
- Agree on ownership and costs. Keep the cloud provider, infrastructure owner and application operator explicit in your quote. The quote identifies the agreed charges and who pays for infrastructure, transfers and operation. A cloud choice alone does not establish that Travila operates inside your own cloud account.
- Verify the selected deployment. At handover, confirm that the deployment uses the agreed provider, region and configuration, that your application works, and that the approved private connection and recovery procedure pass their checks.
Finished result: your application runs in the agreed cloud configuration, with its operating responsibilities, data paths and charges recorded. Unsupported combinations stay blocked; Travila does not silently provision on the other cloud. Any approved external model, integration or shared support path is disclosed separately.
Moving to a different cloud requires a supported migration and your approval of its data transfers, active-work handling, networking, retained copies, recovery and costs. Selecting a cloud does not enable automatic failover to another provider.
4. Choose hosting, backup and recovery regions
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#hosting-region.
Select a primary hosting region from the qualified choices on your selected cloud, then agree where backups and disaster recovery may run. Review the locations against your organization's requirements before creating or moving workloads. A requested region becomes an option only when the required capabilities and dependencies are supported there.
Review where each part of the application stores or processes information:
| Information or activity | What to confirm |
|---|---|
| Application records, files, memory and evaluation results | Primary processing and storage locations, temporary copies, exports and deletion handling |
| Backups and disaster recovery | Approved copy locations, restore destinations and recovery restrictions |
| Logs, traces and monitoring | Destinations, retained content and who can access it |
| Models and integrations | Provider processing locations and permitted fallback destinations |
| Support and diagnostics | Where support artifacts may be stored and from where authorized support may access them |
An incompatible model, integration or monitoring destination blocks that configuration until an approved alternative is selected. Routing, fallback and recovery stay within the agreed restrictions; a failure does not silently move protected data elsewhere.
Each project's primary region remains fixed. Moving an existing application to another region requires a separately approved migration to a new project, with a supported data transfer, active-work plan, validation, rollback and retained-copy handling. Changing a billing plan does not relocate the application.
5. Connect private applications through VPC peering
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#private-connectivity.
Use an approved VPC peering connection when Travila needs to reach applications or services on your private network, or your network needs private access to the selected deployment. VPC peering connects the agreed virtual private cloud networks. Confirm that the deployment supports your cloud, network layout and required traffic direction before planning the connection.
- Define the connection. List the applications, allowed destinations and ports, traffic direction and owners of both network ends. Identify the deployment and projects allowed to use it.
- Check prerequisites. Have the network owners review network identifiers, non-overlapping IP address ranges (CIDRs), routing and return paths, firewall rules and private domain-name resolution (DNS). Confirm whether the supported layout meets your needs; do not assume the connection also reaches a third network through another peer.
- Prepare both ends. Complete the required approvals, configure the agreed routes and DNS, and retain the connection reference with its owners. The onboarding record shows what is pending or blocked before activation.
- Verify the intended access. Test name resolution and a permitted application request from each approved direction. Confirm that unauthorized callers and unrelated destinations remain blocked. Keep application authentication, access controls and encryption in place across the private connection.
- Operate and retire the connection. Monitor its status and use an approved change plan for new destinations, network changes or removal. Recheck access after a change and confirm that removed routes and permissions no longer allow traffic. A failed or removed connection visibly stops affected work without silently switching protected traffic to a public route.
If the supported configuration offers a private endpoint instead, review it as a separate connection option with its own prerequisites and limits. Keep private connectivity in the deployment handover and commercial offer.
6. Prepare the deployment and complete handover
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#release-adoption.
Carry the approved operating arrangement, dedicated scope, cloud provider, regions and private connections into one onboarding plan. Your team installs a self-hosted release; Travila provisions a managed dedicated deployment. Each side completes its assigned setup and acceptance steps before admitting customer workloads:
- Review the release’s supported features, known limits, prerequisites and use terms. Travila supplies installation, configuration, secret-management and recovery instructions for that release.
- Confirm the selected cloud and account ownership, agreed compute and data allocation, stores, locations and permitted network destinations. For self-hosting, configure the components your team operates. Connect only the optional external services your application needs.
- Run a representative application journey, such as creating an account, sending an agent message and retrieving a stored file. Record the release and configuration used.
- Follow the documented upgrade, rollback and restore procedures with your application data. Review any work that needs intervention after recovery.
- Verify any private connections and approved data paths. Record the operating owner, support route, monitoring, access, backup and recovery responsibilities, and any unresolved limitations.
The result is an accepted deployment with a known configuration, a working application journey and a recovery procedure the operating team can follow. The handover records which services are ready, which are blocked and who owns each remaining action. Signing a quote or changing a plan does not activate a deployment that has not passed its readiness checks.
A later move between deployment types, operating owners, cloud providers or regions needs a separate supported change plan. Review data transfers, credentials, active work, private connections, retained backups, recovery and charging consequences before approval. Preserve existing protections and history through the move or exit, and confirm the destination before retiring the old deployment.
7. Practice recovery with the application’s data
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#recovery-and-data-boundaries.
Use a controlled copy of the application’s data and the release’s restore procedure. Recover application state, credentials and file references together, then repeat the customer journey exercised during installation. Honor revoked access and applicable deletion restrictions. Before serving work, inspect missing data and unresolved external operations; retain the recovered point, time taken and remaining operator steps.
Recovery and availability commitments need the tested workload, observation period and failure assumptions. This guide supplies no universal uptime, recovery-time or data-loss guarantee. Confirm any contractual commitments through the approved commercial agreement.
If your deployment consumes infrastructure or object-change events, use the supported source and recovery procedure. Travila reconciles duplicate, delayed and missing events with the current object: an old delete cannot remove its replacement, and an old completion cannot recreate deleted data. Repeated delivery of the same notification does not create another usage charge.
8. Upgrade while accounting for active work
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#active-work-and-upgrades.
Before an upgrade, agree on the affected capabilities, admission or pause behavior, active-work handling, customer communication and recovery procedure. Follow the release’s update steps, confirm the application can accept work again and identify previously admitted work that still needs intervention. Use the compatible rollback procedure if the update cannot complete.
A lost connection, timeout or stopped process may leave an external action's outcome uncertain. Preserve its request or operation reference and reconcile it before repeating an action that could create another effect. A rollback preserves the history and status of work accepted before the change.
The operating view shows which capabilities and modes can accept work, which dependency needs attention and when the status was last observed. Missing monitoring data appears as a gap, so a running process does not conceal an unavailable application feature.
Recover a failed or uncertain application operation
Status: Upcoming — not yet available.
Section: DOC-EN-deployment-operations#operational-incidents.
Record the affected capability, deployment release/configuration, time range, visible errors and request or operation references. Use the approved support channel and share only the diagnostic information it authorizes. Keep credentials and customer content out of general incident reports.
Distinguish failed work from pending or uncertain work, and identify whether the observation itself is stale. Follow the supported recovery procedure and reconcile outstanding external effects before resubmission. If independent incident information is available for your deployment, check its observation time and affected scope.
See assurance and support for reviewing operating evidence and incident communication, billing and spend for usage and payment boundaries, and Travila for Enterprise for related guides.
Document ID: DOC-EN-deployment-operations. Section identities and revisions.