Search Results

Welcome to the Cloudbear documentation, both for information regarding our service offering - as well as documentation regarding our automation platform. The docs are constantly evolving and we are working to cover most important topics in here. Under the Shel...

The Cloudbear Automation Platform (CAP) is a powerful tool designed to simplify the deployment and management of your applications. CAP transforms a simple YAML configuration file into the complex underlying infrastructure required to run your services efficie...

CAP provides a powerful and flexible configuration system that allows you to define a base configuration and then override it for specific instances or environments. Understanding this hierarchy is key to managing your application deployments efficiently. Merg...

Setting type in your config.cap.yaml tells CAP what framework you are running, so it can fill in the parts of a deployment that follow from it: type: laravel Four things change when you set it: Default services are created for you. Most types get a db servi...

CAP provides two powerful ways to manage variations of your application's configuration: Instances and Environments. Understanding the difference between them is key to effectively structuring your config.cap.yaml. Instances: Use instances when you need to de...

Environment variables are defined under a variables key. The keys you provide are the names of the environment variables. A variable is either a plain string or an object, when you need to control build-time availability or mount it as a file. A top-level va...

The http block in your config.cap.yaml defines how your application's web server is exposed and configured. This includes basic settings like ports and replicas, as well as more advanced options like internal routing and health checks. http: enable: true ...

CAP offers a few services that can be deployed or connected with through our config file. You can always connect to an external service by using environments variables as well. But using CAP simplifies things like framework specific logic and CAP will also han...

The connections block in your config.cap.yaml is a list of services your application needs to connect to. When you define a connection, CAP injects the environment variables your application needs to reach that service. connections: - service: main-db - ...

The workers block in your config.cap.yaml defines background processes that run alongside your main application, for processing queues or handling long-running tasks. Each worker needs a unique name of at most 32 characters, and either a command or a subco...

The cronjobs block in your config.cap.yaml defines tasks that run on a schedule. Each cronjob needs a unique name of at most 32 characters, a schedule, and either a command or a subcommand to run. cronjobs: daily-cleanup: schedule: 0 2 * * * com...

Metrics are collected from a set of web servers, so your metrics appear in our monitoring dashboards. metrics: enable: true path: /metrics scrapeInterval: 60s Options Property Type Description Default enable boolean Whether to collect metrics from your a...

Set access on a service to connect to it yourself, with the client you normally use. services: db: type: mariadb access: true Options Property Type Description Default access boolean or object Whether the service is reachable over Cloudbear Mesh. T...

This document covers other top-level properties in your config.cap.yaml that provide special functionality. Monorepo If your GitLab project contains multiple applications (a "monorepo"), you need to tell CAP how to handle each application individually. The m...

When building your application, CAP supports two different strategies for how your Docker images are created and tagged. The strategy you choose depends on your application's build process and dependencies. You can configure this using the pipeline.unifiedIma...