The test environment is a genuine deployment. Arch microservices run as Docker containers from yml service definitions. Sql Server runs in its own container with a persistent volume. Third-party integrations — such as Postmark for email — use live credentials pointed at test accounts. The full authorization chain operates exactly as it does in production. This is where integration problems surface, and where confidence in your deployment is built.

Sql Server runs in its own container with a persistent data volume. The Control Panel connects to Sql Server and manages all microservice configurations. Each Arch microservice is a container deployed from its yml service definition, connecting to Sql Server and to the Application Api for authorization. Your application server connects to the Application Api and to whichever Apis it uses. All containers communicate over a shared Docker network.

Plan the host before the containers. The test environment needs a machine running Docker and Docker Compose with enough resources to host Sql Server and every Arch microservice you plan to deploy. Decide early whether Sql Server runs as a Docker container on the same host or as a separate managed instance — both work, and the choice affects your connection strings throughout. The Control Panel must be reachable from every microservice container, so plan your Docker network and hostnames accordingly.

Only deploy the Apis your application actually uses. You can add more later by repeating the same setup process for each new one.

If you are deploying the Email Api, you will need a Postmark server token and webhook credentials. Use a dedicated test message stream — this keeps test emails separate from your production sender reputation metrics and prevents accidental delivery to real users.