Service Description
Avrea Service Description
This Service Description forms part of the Agreement between Avrea Ltd ("Avrea") and the Customer and describes the scope, functionalities, and limitations of the Service. Capitalised terms not defined herein have the meanings given to them in the Terms of Service.
In the event of any conflict between this Service Description and an Order Form, the Order Form shall prevail.
1. Service Overview
1.1 Purpose
The Avrea Service ("Service") is a Software as a Service (SaaS) platform that provisions ephemeral, on-demand compute environments for executing CI/CD workflows. The Service enables Customers to run continuous integration and continuous delivery (CI/CD) workloads on dedicated, isolated virtual machines rather than shared infrastructure. The supported CI/CD platforms are listed in the Service's documentation.
1.2 Core Functionality
The Service provides the following capabilities:
a) On-Demand Runner Provisioning
When a Customer's CI/CD workflow requests a runner matching Avrea-managed labels, the Service intercepts the event and provisions a dedicated virtual machine to execute the job. Each virtual machine is single-use and is destroyed after job completion.
b) Workload Isolation
Each CI/CD job executes in an isolated virtual machine using hardware-level virtualization. Virtual machines operate on isolated networking with no direct access to Avrea's internal infrastructure or to other Customers' workloads.
c) CI/CD Platform Integration
Customers connect the Service to their CI/CD platform by installing or configuring the applicable Avrea integration (e.g., a platform app or webhook). The integration receives workflow events and manages runner registration and lifecycle automatically, within the permissions granted by the Customer.
d) Management Console
A web-based console provides Customers with visibility into runner provisioning, job execution status, and organizational settings.
e) Build Cache Management
The Service provides caching capabilities for build artifacts, subject to per-repository storage quotas. Cache data is automatically evicted when quotas are exceeded.
1.3 How the Service Operates
The Service operates as an intermediary between the Customer's CI/CD platform and compute infrastructure:
- A CI/CD workflow is triggered on the Customer's platform (by code push, pull request, schedule, or other event).
- The platform sends a webhook event to the Avrea control plane.
- The Service identifies an available compute node and provisions an ephemeral virtual machine.
- The virtual machine registers as a runner, executes the workflow job, and reports results back to the CI/CD platform.
- Upon job completion, the virtual machine is destroyed.
The Service does not control or modify the content of Customer's CI/CD workflows. The processing logic, build steps, and workflow outcomes are determined entirely by the Customer's workflow definitions.
2. Infrastructure
2.1 Hosting Environment
The Service control plane and Customer workload infrastructure are hosted in data centres located within the European Economic Area (EEA). Customer workloads may execute on cloud instances, bare-metal servers, or a combination thereof, depending on the Customer's subscription plan.
The current hosting regions and infrastructure providers are listed in the Service's documentation.
2.2 Data Storage
The Service uses managed relational database and cache services, accessible only via private network peering from the control plane environment.
Customer data at rest is encrypted using AES-256 (or equivalent) encryption. Data in transit is encrypted using TLS 1.2 or higher.
2.3 Subservice Organizations
Avrea relies on third-party infrastructure providers for hosting, compute, database, and related services. These providers are responsible for physical security, environmental controls, and underlying infrastructure availability at their respective facilities.
The current list of subservice organizations and their roles is maintained in the Service's documentation and, where applicable, in audit reports. Avrea reviews each provider's security attestation reports on at least an annual basis.
3. Technical Requirements
3.1 Customer Prerequisites
To use the Service, the Customer must:
- Maintain an active account on a supported CI/CD platform;
- Install and authorize the applicable Avrea integration with the permissions required for runner provisioning;
- Configure CI/CD workflow files to reference Avrea-managed runner labels; and
- Maintain internet connectivity sufficient to interact with the management console and the CI/CD platform.
3.2 Supported Platforms
The Service supports workloads targeting the following platforms, subject to availability in the Customer's subscription plan:
This Service Description forms part of the Agreement between Avrea Ltd ("Avrea") and the Customer and describes the scope, functionalities, and limitations of the Service. Capitalised terms not defined herein have the meanings given to them in the Terms of Service.
In the event of any conflict between this Service Description and an Order Form, the Order Form shall prevail.
3.3 Integrations
The Service integrates with CI/CD platforms for workflow event processing, runner registration, and related automation. The supported CI/CD platforms at any given time are listed in the Service's documentation.
The Service supports authentication via third-party identity providers using standard OAuth 2.0 and OpenID Connect protocols. The identity providers available at any given time are listed in the Service's documentation and login interface.
Avrea may add or remove support for CI/CD platforms, integrations, and identity providers. The addition of new integrations does not constitute a material change to the Service. Removal of a CI/CD platform that is in active use by the Customer is subject to the deprecation terms in Section 8.4.
4. Service Boundaries and Limitations
4.1 What the Service Does Not Include
The following are explicitly outside the scope of the Service:
a) Workflow Logic and Build Outcomes
The Service provisions and manages the compute environment in which Customer workloads execute. Avrea does not develop, maintain, debug, or guarantee the outcome of Customer's CI/CD workflows, build scripts, or test suites. The Customer is solely responsible for the content and correctness of its workflows.
b) Secret and Credential Management for Workflows
Secrets and credentials used within Customer workflows (e.g., API keys, deployment tokens) are managed by the Customer through the CI/CD platform's secrets management or other mechanisms chosen by the Customer. Avrea does not store, manage, or have access to Customer workflow secrets.
c) Source Code Storage
The Service does not serve as a source code repository. Source code is hosted by the Customer on its chosen version control system. The Service accesses source code only transiently during workflow execution, as directed by the Customer's workflow configuration.
d) Container Registry
The Service does not provide a public or private container registry. Container images used in Customer workflows must be hosted by the Customer or obtained from third-party registries.
e) Persistent Storage Between Jobs
Each runner virtual machine is ephemeral. No state, data, or filesystem content persists between separate job executions. The Service's build cache provides limited caching of build artifacts only, subject to storage quotas.
f) Unsupported CI/CD Platforms
The Service operates only with CI/CD platforms listed as supported in the Service's documentation. Avrea does not guarantee compatibility with platforms not listed as supported.
g) GPU Workloads
The Service does not currently support GPU-accelerated compute instances.
h) Customer-Dedicated Networking
The Service operates on a shared network topology. Per-customer VPC or subnet provisioning is not available.
i) Automated Cost Allocation
The Service does not provide per-repository or per-workflow cost attribution or chargeback reporting beyond what is available in the management console.
4.2 Third-Party Dependencies
The Service depends on the availability of the Customer's CI/CD platform, including its webhook delivery, API, and runner registration systems. Interruptions or degradation of the CI/CD platform may affect the Service's ability to provision runners or report job status, regardless of the availability of Avrea's own infrastructure.
Similarly, outages or performance degradation of the underlying infrastructure providers may impact Service availability. The SLA sets out the applicable exclusions.
4.3 Customer Responsibilities
The Customer is responsible for:
- Managing permissions granted to the Avrea integration on the CI/CD platform, ensuring least-privilege access;
- Configuring appropriate runner labels in workflow files to ensure workloads are dispatched to the intended environment;
- Securing secrets and credentials used within CI/CD workflows;
- Monitoring workflow execution results via the CI/CD platform's own reporting mechanisms;
- Maintaining compliance with the CI/CD platform's terms of service and acceptable use policies for all workloads executed through the Service;
- Notifying Avrea promptly of any actual or suspected security incidents related to the Service; and
- Developing its own business continuity plans to address any inability to access or use the Service.
5. Service Availability and Support
5.1 Availability
Service availability targets, downtime definitions, service credit mechanisms, and exclusions are set out in the Service Level Agreement (SLA), which forms part of the Agreement.
5.2 Scheduled Maintenance
Avrea may perform scheduled maintenance that temporarily affects Service availability. Scheduled maintenance will be communicated at least twenty-four (24) hours in advance via the Service's status page or email. Scheduled maintenance windows are excluded from availability calculations under the SLA.
5.3 Support
Avrea provides technical support for the Service according to the response time targets set out in the SLA. Support covers issues with the Service itself, including runner provisioning failures, console access problems, and Service-related errors.
Support does not cover:
- Debugging or troubleshooting Customer workflow logic, build scripts, or test failures;
- Configuration of Customer's CI/CD platform repositories, organizations, or workflows beyond the Avrea integration;
- Third-party tools, services, or dependencies used within Customer workflows; or
- Performance optimization of Customer workloads.
5.4 Status Page
Avrea maintains a publicly accessible status page providing information on Service availability and known incidents.
6. Security
6.1 Security Measures
Avrea implements the following security measures for the Service:
- Encryption: Data at rest encrypted using AES-256 (or equivalent); data in transit encrypted using TLS 1.2+.
- Access control: Role-based access control with multi-factor authentication required for privileged access to production systems.
- Web application firewall: DDoS protection and IP-based access restrictions for internal API endpoints.
- Workload isolation: Each runner VM is isolated at the hardware virtualization level with no shared state between Customer workloads.
- Ephemeral compute: Runner VMs are single-use and automatically destroyed after job completion, eliminating persistent state between jobs.
- Vulnerability management: Regular vulnerability scanning and periodic penetration testing of the production environment.
- Secrets management: Service credentials and keys are stored in a dedicated secrets management service with access restricted to authorized services.
6.2 Compliance
Avrea maintains an Information Security Management System (ISMS) based on the ISO 27001:2022 framework and is actively pursuing both ISO 27001:2022 certification and SOC 2 Type II attestation (Security, Availability, Confidentiality). As of the date of this document, neither certification nor attestation has been obtained. Avrea does not warrant compliance with any specific security framework or standard.
Upon obtaining certifications or attestations, Avrea will make reports available to Customers upon request under non-disclosure agreement and update this Service Description accordingly.
6.3 Incident Response
Avrea maintains an incident response plan covering identification, classification, containment, resolution, and post-incident review of security events. Customers are notified of security incidents that materially affect their data or use of the Service, in accordance with the timeframes required by applicable law and the Agreement.
7. Data Handling
7.1 Data Processed by the Service
The Service processes the following categories of Customer-related data:
7.2 Data Not Stored by Avrea
The Service does not persistently store:
- Workflow output (stdout/stderr): Job output is reported directly from the runner to the CI/CD platform and is not retained by Avrea.
- Customer source code: Source code is fetched by the runner during execution and is deleted with the VM upon job completion.
- Customer secrets: Workflow secrets are managed by the CI/CD platform and are never transmitted to or stored by Avrea's control plane.
7.3 Data Export and Deletion
Upon termination or expiry of the Agreement, the Customer may request export of its Service Data within thirty (30) days, after which Avrea will delete such data in accordance with the Agreement. Ephemeral runner data (VM state, execution artefacts) is not available for export as it is destroyed upon job completion.
7.4 Data Processing
Where Customer data includes personal data, Avrea processes such data as a data processor on behalf of the Customer (as data controller). Where a Data Processing Agreement (DPA) is in place, personal data is processed in accordance with its terms. Otherwise, Avrea processes personal data in accordance with its Privacy Policy and applicable data protection law.
8. Service Lifecycle
8.1 Updates and Changes
Avrea continuously develops and improves the Service. Changes may include:
- Bug fixes and security patches: Applied as needed to maintain the security and stability of the Service. These may be deployed without advance notice.
- Feature improvements: Enhancements to existing functionality, deployed as part of regular release cycles.
- New features: New capabilities may be introduced and made available according to the Customer's subscription plan.
Avrea reserves the right to modify, update, or discontinue features of the Service, provided that such changes do not materially reduce the core functionality described in Section 1.2 during the Customer's then-current subscription term. Material changes to Service functionality will be communicated with reasonable advance notice.
8.2 Backward Compatibility
Avrea endeavours to maintain backward compatibility for Customer-facing integrations (webhook processing, runner label syntax, console functionality). Where a breaking change is necessary, Avrea will provide reasonable notice and, where practical, a migration period.
8.3 Beta Features
Avrea may make certain features available as beta or early access. Beta features are provided "as is" without any availability or support commitments and may be modified or discontinued at any time. Beta features are identified as such in the console or documentation. Unless the Customer explicitly opts in, beta features are not enabled on the Customer's account.
8.4 Deprecation
When Avrea deprecates a Service feature, it will:
- Provide notice of the deprecation through the console, status page, or email;
- Allow a reasonable transition period (no less than ninety (90) days for features described in Section 1.2) before removal; and
- Where feasible, provide guidance on alternative approaches or successor features.
