architect.yml
Architect.io Component
| Type | object |
|---|---|
| File match |
architect.yml
architect.yaml
*.architect.yml
*.architect.yaml
|
| Schema URL | https://catalog.lintel.tools/schemas/schemastore/architect-yml/latest.json |
| Source | https://raw.githubusercontent.com/architect-team/architect-cli/main/src/dependency-manager/schema/architect.schema.json |
Validate with Lintel
npx @lintel/lintel checkThe top level object of the architect.yml; defines a deployable Architect Component.
Properties
Globally unique friendly reference to the component. must contain only lower alphanumeric and single hyphens in the middle; max length 32
A human-readable description of the component. This will be rendered when potential consumers view the component so that they know what it should be used for.
Additional search terms to be used when the component is indexed so that others can find it more easily.
The name or handle of the author of the component as a developer contact.
The url that serves as the informational homepage of the component (i.e. a github repo).
A map of named, configurable fields for the component. If a component contains properties that differ across environments (i.e. environment variables), you'll want to capture them as secrets. Specifying a primitive value here will set the default secret value. For more detailed configuration, specify a SecretDefinitionSpec
A map of named, configurable outputs for the component. Outputs allow components to expose configuration details that should be shared with consumers, like API keys or notification topic names.
A database represents a stateful service powered by one of several supported database engines.
A Service represents a non-exiting runtime (e.g. daemons, servers, etc.). Each service is independently deployable and scalable. Services are 1:1 with a docker image.
A set of named recurring and/or exiting runtimes (e.g. crons, schedulers, triggered jobs) included with the component. Each task will run on its specified schedule and/or be triggerable via the Architect CLI. Tasks are 1:1 with a docker image.
A key-value set of dependencies with an empty value. Reference each dependency by component name (e.g. cloud: {})
A set of named gateways that broker access to the services inside the component. All network traffic within a component is locked down to the component itself, unless included in this interfaces block. An interface represents a front-door to your component, granting access to upstream callers.
Definitions
Component databases let you quickly spin up a database for your service
The type engine and version of database software needed for data storage.
Human readable description
The connection uri of an existing database to use instead of provisioning a new one
Components can define configurable secrets that can be used to enrich the contained services with environment-specific information (i.e. environment variables).
Denotes whether the secret is required.
A human-friendly description of the secret.
Sets a default value for the secret if one is not provided
Configuration for service health checks. Architect uses health checks are used for load balancing and rolling updates.
The number of times to retry a health check before the container is considered healthy.
The number of times to retry a failed health check before the container is considered unhealthy.
The time period to wait for a health check to succeed before it is considered a failure. You may specify any value between: 2s and 60s
The time period in seconds between each health check execution. You may specify any value between: 5s and 300s
Delays the check from running for the specified amount of time
[Deprecated: use command instead.] Path for the http check executable. Path should be absolute (e.g. /health). If path is set, port also must be set. This field is disjunctive with command (only one of path or command can be set).
Command that runs the http check. This field is disjunctive with path and port (only one of command or path/port can be set).
[Deprecated: use command instead.] Port that the http check will run against. If port is set, path also must be set. This field is disjunctive with command (only one of port or command can be set).
Architect can mount volumes onto your services and tasks to store data that should be shared between running containers or that should persist beyond the lifetime of a container.
Directory at which the volume will be mounted inside the container.
A directory on the host machine to sync with the mount_path on the docker image. This field is only relevant inside the debug block for local deployments. This field is disjunctive with key (only one of host_path or key can be set).
A reference to the underlying volume on the deployment cluster of choice. The docker-compose volume name, the name of the Kubernetes PersistentVolumeClaim, or the EFS ID of an AWS volume. This field is disjunctive with host_path (only one of key or host_path can be set).
Human-readable description of volume
Marks the volume as readonly.
An object containing the details necessary for Architect to build the service via Docker. Whenever a service that specifies a build field is registered with Architect, the CLI will trigger a docker build and replace the build field with a resolvable image.
The path to the directory containing the source code relative to the architect.yml file.
Option to use buildpack to build an image.
Build args to be passed into docker build.
The path to the Dockerfile relative to the build.context
The stage to build in the Dockerfile
Configuration for custom certificate.
Custom certificate.
Custom certificate key.
Custom certificate ca.
An ingress exposes an interface to external network traffic through an architect-deployed gateway.
Marks the interface as an ingress.
The subdomain that will be used if the interface is exposed externally. Use subdomain: @ to target the base domain.
Configuration for custom certificate.
3 nested properties
Custom certificate.
Custom certificate key.
Custom certificate ca.
The path of the interface used for path based routing
IP addresses that are allowed to access the interface
Marks the ingress as private behind Architect authentication
Scaling metrics define the upper bound of resource consumption before spinning up an additional replica.
The cpu usage required to trigger scaling.
The memory usage required to trigger scaling.
Configuration that dictates the scaling behavior of a service.
The target minimum number of service replicas.
The target maximum number of service replicas.
Scaling metrics define the upper bound of resource consumption before spinning up an additional replica.
2 nested properties
The cpu usage required to trigger scaling.
The memory usage required to trigger scaling.
Configuration that dictates the kubernetes deploy overrides.
Configuration that dictates the deploy overrides.
Configuration that dictates the kubernetes deploy overrides.
1 nested properties
A service interface exposes service functionality over the network to other services within the same component. If you would like to expose services on the network to external components, see the ComponentInterfaceSpec
Port on which the service is listening for traffic.
A human-readable description of the interface.
The host address of an existing service to use instead of provisioning a new one. Setting this field effectively overrides any deployment of this service and directs all traffic to the given host.
Protocol that the interface responds to
A Basic Auth username required to access the interface
A Basic Auth password required to access the interface
The path of the interface
The url of an existing service to use instead of provisioning a new one. Setting this field effectively overrides any deployment of this service and directs all traffic to the given url.
Denotes that if this interface is made external, the gateway should use sticky sessions
An ingress exposes an interface to external network traffic through an architect-deployed gateway.
6 nested properties
Marks the interface as an ingress.
The subdomain that will be used if the interface is exposed externally. Use subdomain: @ to target the base domain.
Configuration for custom certificate.
3 nested properties
Custom certificate.
Custom certificate key.
Custom certificate ca.
The path of the interface used for path based routing
IP addresses that are allowed to access the interface
Marks the ingress as private behind Architect authentication
A runtimes (e.g. daemons, servers, etc.). Each service is independently deployable and scalable. Services are 1:1 with a docker image.
Determines if the service should be running.
A runtimes (e.g. daemons, servers, etc.). Each service is independently deployable and scalable. Services are 1:1 with a docker image.
20 nested properties
Determines if the service should be running.
A set of named interfaces to expose service functionality over the network to other services within the same component. A string or number represents the TCP port that the service is listening on. For more detailed configuration, specify a full ServiceInterfaceSpec object.
Configuration for service health checks. Architect uses health checks are used for load balancing and rolling updates.
8 nested properties
The number of times to retry a health check before the container is considered healthy.
The number of times to retry a failed health check before the container is considered unhealthy.
The time period to wait for a health check to succeed before it is considered a failure. You may specify any value between: 2s and 60s
The time period in seconds between each health check execution. You may specify any value between: 5s and 300s
Delays the check from running for the specified amount of time
[Deprecated: use command instead.] Path for the http check executable. Path should be absolute (e.g. /health). If path is set, port also must be set. This field is disjunctive with command (only one of path or command can be set).
Command that runs the http check. This field is disjunctive with path and port (only one of command or path/port can be set).
[Deprecated: use command instead.] Port that the http check will run against. If port is set, path also must be set. This field is disjunctive with command (only one of port or command can be set).
A set of named volumes to be mounted at deploy-time. Take advantage of volumes to store data that should be shared between running containers or that should persist beyond the lifetime of a container.
A static number of replicas of a service to be deployed. For scaling configuration, see scaling field.
Configuration that dictates the scaling behavior of a service.
3 nested properties
The target minimum number of service replicas.
The target maximum number of service replicas.
Scaling metrics define the upper bound of resource consumption before spinning up an additional replica.
Configuration that dictates the deploy overrides.
1 nested properties
Configuration that dictates the kubernetes deploy overrides.
A period of time between a service being passed a SIGINT and a SIGTERM when it's scheduled to be replaced or terminated. Only used for remote deployments.
Human readable description
The docker image that serves as the unit of runtime. This field is disjunctive with build (only one of image or build can be set)
The docker startup command. Use this if you need to override or parameterize or parameterize the docker image command.
The docker entrypoint for the container. Use this if you need to override or parameterize the docker image entrypoint.
The dominant programming language used; this is for informational purposes only.
A set of key-value pairs or secret definitions that describes environment variables and their values.
An object containing the details necessary for Architect to build the service via Docker. Whenever a service that specifies a build field is registered with Architect, the CLI will trigger a docker build and replace the build field with a resolvable image.
5 nested properties
The path to the directory containing the source code relative to the architect.yml file.
Option to use buildpack to build an image.
Build args to be passed into docker build.
The path to the Dockerfile relative to the build.context
The stage to build in the Dockerfile
The cpu required to run a service or a task
The memory required to run a service or a task.
An array of service names for those services in the component that are pre-requisites to deploy. Used at deploy-time to build a deploy order across services and tasks.
A simple key-value annotation store; useful to organize, categorize, scope, and select services and tasks.
A specific service name which will override the service name specified in the component.
A set of named interfaces to expose service functionality over the network to other services within the same component. A string or number represents the TCP port that the service is listening on. For more detailed configuration, specify a full ServiceInterfaceSpec object.
Configuration for service health checks. Architect uses health checks are used for load balancing and rolling updates.
8 nested properties
The number of times to retry a health check before the container is considered healthy.
The number of times to retry a failed health check before the container is considered unhealthy.
The time period to wait for a health check to succeed before it is considered a failure. You may specify any value between: 2s and 60s
The time period in seconds between each health check execution. You may specify any value between: 5s and 300s
Delays the check from running for the specified amount of time
[Deprecated: use command instead.] Path for the http check executable. Path should be absolute (e.g. /health). If path is set, port also must be set. This field is disjunctive with command (only one of path or command can be set).
Command that runs the http check. This field is disjunctive with path and port (only one of command or path/port can be set).
[Deprecated: use command instead.] Port that the http check will run against. If port is set, path also must be set. This field is disjunctive with command (only one of port or command can be set).
A set of named volumes to be mounted at deploy-time. Take advantage of volumes to store data that should be shared between running containers or that should persist beyond the lifetime of a container.
A static number of replicas of a service to be deployed. For scaling configuration, see scaling field.
Configuration that dictates the scaling behavior of a service.
3 nested properties
The target minimum number of service replicas.
The target maximum number of service replicas.
Scaling metrics define the upper bound of resource consumption before spinning up an additional replica.
2 nested properties
The cpu usage required to trigger scaling.
The memory usage required to trigger scaling.
Configuration that dictates the deploy overrides.
1 nested properties
Configuration that dictates the kubernetes deploy overrides.
1 nested properties
A period of time between a service being passed a SIGINT and a SIGTERM when it's scheduled to be replaced or terminated. Only used for remote deployments.
Human readable description
The docker image that serves as the unit of runtime. This field is disjunctive with build (only one of image or build can be set)
The docker startup command. Use this if you need to override or parameterize or parameterize the docker image command.
The docker entrypoint for the container. Use this if you need to override or parameterize the docker image entrypoint.
The dominant programming language used; this is for informational purposes only.
A set of key-value pairs or secret definitions that describes environment variables and their values.
An object containing the details necessary for Architect to build the service via Docker. Whenever a service that specifies a build field is registered with Architect, the CLI will trigger a docker build and replace the build field with a resolvable image.
5 nested properties
The path to the directory containing the source code relative to the architect.yml file.
Option to use buildpack to build an image.
Build args to be passed into docker build.
The path to the Dockerfile relative to the build.context
The stage to build in the Dockerfile
The cpu required to run a service or a task
The memory required to run a service or a task.
An array of service names for those services in the component that are pre-requisites to deploy. Used at deploy-time to build a deploy order across services and tasks.
A simple key-value annotation store; useful to organize, categorize, scope, and select services and tasks.
A specific service name which will override the service name specified in the component.
A Task represents a recurring and/or exiting runtime (e.g. crons, schedulers, triggered jobs). Each task will run on its specified schedule and/or be triggerable via the Architect CLI. Tasks are 1:1 with a docker image.
A Task represents a recurring and/or exiting runtime (e.g. crons, schedulers, triggered jobs). Each task will run on its specified schedule and/or be triggerable via the Architect CLI. Tasks are 1:1 with a docker image.
13 nested properties
A cron expression by which this task will be scheduled. Leave blank to deploy a task that never runs unless triggered from the CLI.
Human readable description
The docker image that serves as the unit of runtime. This field is disjunctive with build (only one of image or build can be set)
The docker startup command. Use this if you need to override or parameterize or parameterize the docker image command.
The docker entrypoint for the container. Use this if you need to override or parameterize the docker image entrypoint.
The dominant programming language used; this is for informational purposes only.
A set of key-value pairs or secret definitions that describes environment variables and their values.
An object containing the details necessary for Architect to build the service via Docker. Whenever a service that specifies a build field is registered with Architect, the CLI will trigger a docker build and replace the build field with a resolvable image.
5 nested properties
The path to the directory containing the source code relative to the architect.yml file.
Option to use buildpack to build an image.
Build args to be passed into docker build.
The path to the Dockerfile relative to the build.context
The stage to build in the Dockerfile
The cpu required to run a service or a task
The memory required to run a service or a task.
An array of service names for those services in the component that are pre-requisites to deploy. Used at deploy-time to build a deploy order across services and tasks.
A simple key-value annotation store; useful to organize, categorize, scope, and select services and tasks.
A specific service name which will override the service name specified in the component.
A cron expression by which this task will be scheduled. Leave blank to deploy a task that never runs unless triggered from the CLI.
Human readable description
The docker image that serves as the unit of runtime. This field is disjunctive with build (only one of image or build can be set)
The docker startup command. Use this if you need to override or parameterize or parameterize the docker image command.
The docker entrypoint for the container. Use this if you need to override or parameterize the docker image entrypoint.
The dominant programming language used; this is for informational purposes only.
A set of key-value pairs or secret definitions that describes environment variables and their values.
An object containing the details necessary for Architect to build the service via Docker. Whenever a service that specifies a build field is registered with Architect, the CLI will trigger a docker build and replace the build field with a resolvable image.
5 nested properties
The path to the directory containing the source code relative to the architect.yml file.
Option to use buildpack to build an image.
Build args to be passed into docker build.
The path to the Dockerfile relative to the build.context
The stage to build in the Dockerfile
The cpu required to run a service or a task
The memory required to run a service or a task.
An array of service names for those services in the component that are pre-requisites to deploy. Used at deploy-time to build a deploy order across services and tasks.
A simple key-value annotation store; useful to organize, categorize, scope, and select services and tasks.
A specific service name which will override the service name specified in the component.
An empty object that optionally supports specifying a tag for backwards compatibility.
Component Interfaces are the primary means by which components advertise their resolvable addresses to others. Interfaces are the only means by which other components can communicate with your component.
The url that the component interface should forward to.
An ingress exposes an interface to external network traffic through an architect-deployed gateway.
6 nested properties
Marks the interface as an ingress.
The subdomain that will be used if the interface is exposed externally. Use subdomain: @ to target the base domain.
Configuration for custom certificate.
3 nested properties
Custom certificate.
Custom certificate key.
Custom certificate ca.
The path of the interface used for path based routing
IP addresses that are allowed to access the interface
Marks the ingress as private behind Architect authentication
A human-readable description of the component. This will be rendered when potential consumers view the interface so that they know what it should be used for.
The host that the component interface should forward to.
The port that the component interface should forward to.
The protocol by which the component interface can be connected to.
The Basic Auth username by which a component interface can be connected to.
The Basic Auth password by which a component interface can be connected to.
If this interface is made into an external ingress, sticky=true will denote the gateway should use sticky sessions if more than one replica is running.
Components can define output fields that can be used to share configuration with consuming components.
Value of the output to be passed to upstream consumers
A human-friendly description of the output field.
The top level object of the architect.yml; defines a deployable Architect Component.
Globally unique friendly reference to the component. must contain only lower alphanumeric and single hyphens in the middle; max length 32
A human-readable description of the component. This will be rendered when potential consumers view the component so that they know what it should be used for.
Additional search terms to be used when the component is indexed so that others can find it more easily.
The name or handle of the author of the component as a developer contact.
The url that serves as the informational homepage of the component (i.e. a github repo).
A map of named, configurable fields for the component. If a component contains properties that differ across environments (i.e. environment variables), you'll want to capture them as secrets. Specifying a primitive value here will set the default secret value. For more detailed configuration, specify a SecretDefinitionSpec
A map of named, configurable outputs for the component. Outputs allow components to expose configuration details that should be shared with consumers, like API keys or notification topic names.
A database represents a stateful service powered by one of several supported database engines.
A Service represents a non-exiting runtime (e.g. daemons, servers, etc.). Each service is independently deployable and scalable. Services are 1:1 with a docker image.
A set of named recurring and/or exiting runtimes (e.g. crons, schedulers, triggered jobs) included with the component. Each task will run on its specified schedule and/or be triggerable via the Architect CLI. Tasks are 1:1 with a docker image.
A key-value set of dependencies with an empty value. Reference each dependency by component name (e.g. cloud: {})
A set of named gateways that broker access to the services inside the component. All network traffic within a component is locked down to the component itself, unless included in this interfaces block. An interface represents a front-door to your component, granting access to upstream callers.
Component databases let you quickly spin up a database for your service
Human readable description
The type engine and version of database software needed for data storage.
The connection uri of an existing database to use instead of provisioning a new one
Components can define configurable secrets that can be used to enrich the contained services with environment-specific information (i.e. environment variables).
Denotes whether the secret is required.
A human-friendly description of the secret.
Sets a default value for the secret if one is not provided
Configuration for service health checks. Architect uses health checks are used for load balancing and rolling updates.
The number of times to retry a health check before the container is considered healthy.
The number of times to retry a failed health check before the container is considered unhealthy.
The time period to wait for a health check to succeed before it is considered a failure. You may specify any value between: 2s and 60s
The time period in seconds between each health check execution. You may specify any value between: 5s and 300s
Delays the check from running for the specified amount of time
[Deprecated: use command instead.] Path for the http check executable. Path should be absolute (e.g. /health). If path is set, port also must be set. This field is disjunctive with command (only one of path or command can be set).
Command that runs the http check. This field is disjunctive with path and port (only one of command or path/port can be set).
[Deprecated: use command instead.] Port that the http check will run against. If port is set, path also must be set. This field is disjunctive with command (only one of port or command can be set).
Architect can mount volumes onto your services and tasks to store data that should be shared between running containers or that should persist beyond the lifetime of a container.
Directory at which the volume will be mounted inside the container.
A directory on the host machine to sync with the mount_path on the docker image. This field is only relevant inside the debug block for local deployments. This field is disjunctive with key (only one of host_path or key can be set).
A reference to the underlying volume on the deployment cluster of choice. The docker-compose volume name, the name of the Kubernetes PersistentVolumeClaim, or the EFS ID of an AWS volume. This field is disjunctive with host_path (only one of key or host_path can be set).
Human-readable description of volume
Marks the volume as readonly.
An object containing the details necessary for Architect to build the service via Docker. Whenever a service that specifies a build field is registered with Architect, the CLI will trigger a docker build and replace the build field with a resolvable image.
The path to the directory containing the source code relative to the architect.yml file.
Option to use buildpack to build an image.
Build args to be passed into docker build.
The path to the Dockerfile relative to the build.context
The stage to build in the Dockerfile
Configuration for custom certificate.
Custom certificate.
Custom certificate key.
Custom certificate ca.
An ingress exposes an interface to external network traffic through an architect-deployed gateway.
Marks the interface as an ingress.
The subdomain that will be used if the interface is exposed externally. Use subdomain: @ to target the base domain.
Configuration for custom certificate.
3 nested properties
Custom certificate.
Custom certificate key.
Custom certificate ca.
The path of the interface used for path based routing
IP addresses that are allowed to access the interface
Marks the ingress as private behind Architect authentication
Scaling metrics define the upper bound of resource consumption before spinning up an additional replica.
The cpu usage required to trigger scaling.
The memory usage required to trigger scaling.
Configuration that dictates the scaling behavior of a service.
The target minimum number of service replicas.
The target maximum number of service replicas.
Scaling metrics define the upper bound of resource consumption before spinning up an additional replica.
2 nested properties
The cpu usage required to trigger scaling.
The memory usage required to trigger scaling.
Configuration that dictates the kubernetes deploy overrides.
Configuration that dictates the deploy overrides.
Configuration that dictates the kubernetes deploy overrides.
1 nested properties
A service interface exposes service functionality over the network to other services within the same component. If you would like to expose services on the network to external components, see the ComponentInterfaceSpec
A human-readable description of the interface.
The host address of an existing service to use instead of provisioning a new one. Setting this field effectively overrides any deployment of this service and directs all traffic to the given host.
Port on which the service is listening for traffic.
Protocol that the interface responds to
A Basic Auth username required to access the interface
A Basic Auth password required to access the interface
The path of the interface
The url of an existing service to use instead of provisioning a new one. Setting this field effectively overrides any deployment of this service and directs all traffic to the given url.
Denotes that if this interface is made external, the gateway should use sticky sessions
An ingress exposes an interface to external network traffic through an architect-deployed gateway.
6 nested properties
Marks the interface as an ingress.
The subdomain that will be used if the interface is exposed externally. Use subdomain: @ to target the base domain.
Configuration for custom certificate.
3 nested properties
Custom certificate.
Custom certificate key.
Custom certificate ca.
The path of the interface used for path based routing
IP addresses that are allowed to access the interface
Marks the ingress as private behind Architect authentication
A runtimes (e.g. daemons, servers, etc.). Each service is independently deployable and scalable. Services are 1:1 with a docker image.
Determines if the service should be running.
A set of named interfaces to expose service functionality over the network to other services within the same component. A string or number represents the TCP port that the service is listening on. For more detailed configuration, specify a full ServiceInterfaceSpec object.
Configuration for service health checks. Architect uses health checks are used for load balancing and rolling updates.
8 nested properties
The number of times to retry a health check before the container is considered healthy.
The number of times to retry a failed health check before the container is considered unhealthy.
The time period to wait for a health check to succeed before it is considered a failure. You may specify any value between: 2s and 60s
The time period in seconds between each health check execution. You may specify any value between: 5s and 300s
Delays the check from running for the specified amount of time
[Deprecated: use command instead.] Path for the http check executable. Path should be absolute (e.g. /health). If path is set, port also must be set. This field is disjunctive with command (only one of path or command can be set).
Command that runs the http check. This field is disjunctive with path and port (only one of command or path/port can be set).
[Deprecated: use command instead.] Port that the http check will run against. If port is set, path also must be set. This field is disjunctive with command (only one of port or command can be set).
A set of named volumes to be mounted at deploy-time. Take advantage of volumes to store data that should be shared between running containers or that should persist beyond the lifetime of a container.
A static number of replicas of a service to be deployed. For scaling configuration, see scaling field.
Configuration that dictates the scaling behavior of a service.
3 nested properties
The target minimum number of service replicas.
The target maximum number of service replicas.
Scaling metrics define the upper bound of resource consumption before spinning up an additional replica.
2 nested properties
The cpu usage required to trigger scaling.
The memory usage required to trigger scaling.
Configuration that dictates the deploy overrides.
1 nested properties
Configuration that dictates the kubernetes deploy overrides.
1 nested properties
A period of time between a service being passed a SIGINT and a SIGTERM when it's scheduled to be replaced or terminated. Only used for remote deployments.
Human readable description
The docker image that serves as the unit of runtime. This field is disjunctive with build (only one of image or build can be set)
The docker startup command. Use this if you need to override or parameterize or parameterize the docker image command.
The docker entrypoint for the container. Use this if you need to override or parameterize the docker image entrypoint.
The dominant programming language used; this is for informational purposes only.
A set of key-value pairs or secret definitions that describes environment variables and their values.
An object containing the details necessary for Architect to build the service via Docker. Whenever a service that specifies a build field is registered with Architect, the CLI will trigger a docker build and replace the build field with a resolvable image.
5 nested properties
The path to the directory containing the source code relative to the architect.yml file.
Option to use buildpack to build an image.
Build args to be passed into docker build.
The path to the Dockerfile relative to the build.context
The stage to build in the Dockerfile
The cpu required to run a service or a task
The memory required to run a service or a task.
An array of service names for those services in the component that are pre-requisites to deploy. Used at deploy-time to build a deploy order across services and tasks.
A simple key-value annotation store; useful to organize, categorize, scope, and select services and tasks.
A specific service name which will override the service name specified in the component.
A Task represents a recurring and/or exiting runtime (e.g. crons, schedulers, triggered jobs). Each task will run on its specified schedule and/or be triggerable via the Architect CLI. Tasks are 1:1 with a docker image.
A cron expression by which this task will be scheduled. Leave blank to deploy a task that never runs unless triggered from the CLI.
Human readable description
The docker image that serves as the unit of runtime. This field is disjunctive with build (only one of image or build can be set)
The docker startup command. Use this if you need to override or parameterize or parameterize the docker image command.
The docker entrypoint for the container. Use this if you need to override or parameterize the docker image entrypoint.
The dominant programming language used; this is for informational purposes only.
A set of key-value pairs or secret definitions that describes environment variables and their values.
An object containing the details necessary for Architect to build the service via Docker. Whenever a service that specifies a build field is registered with Architect, the CLI will trigger a docker build and replace the build field with a resolvable image.
5 nested properties
The path to the directory containing the source code relative to the architect.yml file.
Option to use buildpack to build an image.
Build args to be passed into docker build.
The path to the Dockerfile relative to the build.context
The stage to build in the Dockerfile
The cpu required to run a service or a task
The memory required to run a service or a task.
An array of service names for those services in the component that are pre-requisites to deploy. Used at deploy-time to build a deploy order across services and tasks.
A simple key-value annotation store; useful to organize, categorize, scope, and select services and tasks.
A specific service name which will override the service name specified in the component.
An empty object that optionally supports specifying a tag for backwards compatibility.
Component Interfaces are the primary means by which components advertise their resolvable addresses to others. Interfaces are the only means by which other components can communicate with your component.
An ingress exposes an interface to external network traffic through an architect-deployed gateway.
6 nested properties
Marks the interface as an ingress.
The subdomain that will be used if the interface is exposed externally. Use subdomain: @ to target the base domain.
Configuration for custom certificate.
3 nested properties
Custom certificate.
Custom certificate key.
Custom certificate ca.
The path of the interface used for path based routing
IP addresses that are allowed to access the interface
Marks the ingress as private behind Architect authentication
A human-readable description of the component. This will be rendered when potential consumers view the interface so that they know what it should be used for.
The host that the component interface should forward to.
The port that the component interface should forward to.
The protocol by which the component interface can be connected to.
The Basic Auth username by which a component interface can be connected to.
The Basic Auth password by which a component interface can be connected to.
The url that the component interface should forward to.
If this interface is made into an external ingress, sticky=true will denote the gateway should use sticky sessions if more than one replica is running.
Components can define output fields that can be used to share configuration with consuming components.
A human-friendly description of the output field.
Value of the output to be passed to upstream consumers
The top level object of the architect.yml; defines a deployable Architect Component.
Globally unique friendly reference to the component. must contain only lower alphanumeric and single hyphens in the middle; max length 32
A human-readable description of the component. This will be rendered when potential consumers view the component so that they know what it should be used for.
Additional search terms to be used when the component is indexed so that others can find it more easily.
The name or handle of the author of the component as a developer contact.
The url that serves as the informational homepage of the component (i.e. a github repo).
A map of named, configurable fields for the component. If a component contains properties that differ across environments (i.e. environment variables), you'll want to capture them as secrets. Specifying a primitive value here will set the default secret value. For more detailed configuration, specify a SecretDefinitionSpec
A map of named, configurable outputs for the component. Outputs allow components to expose configuration details that should be shared with consumers, like API keys or notification topic names.
A database represents a stateful service powered by one of several supported database engines.
A Service represents a non-exiting runtime (e.g. daemons, servers, etc.). Each service is independently deployable and scalable. Services are 1:1 with a docker image.
A set of named recurring and/or exiting runtimes (e.g. crons, schedulers, triggered jobs) included with the component. Each task will run on its specified schedule and/or be triggerable via the Architect CLI. Tasks are 1:1 with a docker image.
A key-value set of dependencies with an empty value. Reference each dependency by component name (e.g. cloud: {})
A set of named gateways that broker access to the services inside the component. All network traffic within a component is locked down to the component itself, unless included in this interfaces block. An interface represents a front-door to your component, granting access to upstream callers.