Architect Core Concepts

Architect's platform is enabled by breaking down application responsibility into a set of loosely coupled data structures and concepts. This separation enables developers and operators to work collaboratively to produce and manage large scale applications, but also affords each role the autonomy to experiment without needing to be intimately aware of each others work and responsibilities. In this guide you'll learn about the two key concepts, services and environments, that enable developers and operators alike to maximize the use of Architect's deployment platform.


Services can be thought of synonymously with microservices and the use of the term in Service-Oriented Architecture (SOA) - each service representing a discrete unit of functionality that can be updated independently of others. Each Architect service is bundled as a Docker image in our registry, but unlike standard Docker images Architect services include the details of what parameters the service supports as well as which other services need to exist and be connected to in order for the service to fulfill its own interface contracts. It's this index of relationship to peers and dependencies that enables Architect to provision related services in concert and broker/secure connectivity between them.

Any Dockerized microservice or application can be easily published to and deployed with Architect with the addition of a service configuration file. These config files are a manifest of the applications features pertinent to its dependency needs and its ability to be integrated with by others. The developers of a service are the source of truth for this information, and by collecting it from them directly Architect is able to remove the operational complexity common with microservice integration.

Steps to create an Architect service

  1. Write your application code
  2. Create a Dockerfile that defines the environment requirements and means of booting the service
  3. Create an architect.json file that outlines your services interface, parameters, and dependencies on other services

Learn more


Architect environments are entities that encapsulate everything needed to produce end-to-end application environments, including the services that need to be exposed to users, parameter and credential settings, networking and monitoring tools, and ingress/egress rules and policies. Since Architect is able to ensure that a services dependencies are deployed automatically, environment managers can better focus on the rules, policies, and configurations that impact the business and environment as a whole without needing to be involved in the integration efforts between developers. Additionally, the ability to easily reproduce complex environments with a variety of different settings empowers operators to test new tools with ease and without needing support from application developers.

Environments can be easily configured, updated, and otherwise managed from Architect's web platform, but they can also be configured and managed via manifest files just like services. These manifest files can be thought of as infrastructure-as-code templates in that they are static representations of an environment to be reproduced, but these templates are application focused and don't need to include references to services that will be deployed implicitly as a result of being a dependency of others. Often times this means these files will only reference one or two web applications or APIs that will be accessible to users no matter how many other dependencies these services connect to behind the scenes - thus ensuring that environments require as little maintenance as possible.

Learn more


Environments and their associated manifests are designed to be able to reproduce an end-to-end application on any cloud provider, and for this reason the container platform and other provisioning tools are configured as a separate entity: an Architect platform. These entities are registered directly with Architect, include the credentials needed to deploy resources to the associated container platform, and are paired directly to one or more environments. Many users will only register a single platform pointing all their environments to it, but businesses may seek to separate platform access based on business risk. A common pattern would be to leverage one platform for dev and on-demand environments (e.g. preview environments for branches and pull requests) and another for higher risk environments like production.

Note: platforms will never be deployed to directly, and will instead be directly associated to environments. Each environment acts as a namespace on the platform, and all deploy jobs will point to an environment for provisioning and encapsulation.

On This Page