Servers

A server in Beaker Studio is a service that consists of one or more tasks which run continously. If a tasks fails, it will be restarted automatically. Servers are useful for running software like websites, message queues, self-managed databases, and background processes.

To create a server, choose Server as the Service Type on the deployment screen.

Parameters

This section describes the possible parameters for servers that appear in the Beaker Studio UI.

Instance Platform

Determines which OS and CPU architecture the service will build and run on. Beaker Studio can deploy both architectures to the same cluster simultaneously, so feel free to mix and match to best serve your needs.

Choice between either Linux x86-64 or Linux ARM64. If your team is developing on M-series Apple devices, then you probably want Linux ARM64. Otherwise, most machines are x86-64.

Windows is not yet supported.

Instance Size

Determines the amount of CPU and memory available to each task in the service. For pricing, see Amazon’s Fargate pricing.

Autodeploy

If enabled, Beaker Studio will automatically deploy the service when you push to the configured branch of your GitHub repository. If disabled, you can manually deploy the service from the Beaker Studio UI.

Command Override

Allows you to override the command specified in compose.yaml. This is useful if you want to run a different command in production than you do locally. For example, you might want to run a production build of your code instead of a development build.

Instance Count

The number of tasks to run by default in the service.

Load Balancing

Whether to enable load balancing for the service. If enabled, Beaker Studio will automatically create a load balancer and route traffic to the service.

Choice between either HTTP/HTTPS and TCP/UDP. If you’re running a web server, you’ll want HTTP/HTTPS. If you’re running a self-managed database, you’ll want TCP/UDP.

A load balancer is required to connect a domain, subdomain, or CDN to a service. This is a hard limitation of AWS.

For load balancer pricing, see Amazon’s Elastic Load Balancing pricing. The HTTP/HTTPS and TCP/UDP load balancers are provisioned as Application Load Balancers and Network Load Balancers, respectively.

Load Balancing Target Port

Which port on the service to route load balancer traffic to. These ports are defined in your compose.yaml.

Load Balancing Ingress Rule

The IP address range that is allowed to access the load balancer.

Choice between either Allow All and Allow from VPC. For public services, you’ll want Allow All. For services that should only be accessed from within the same environment, you’ll want Allow from VPC.

Load Balancing HTTPS

Whether to accept HTTPS traffic on the load balancer. If enabled, you must select a certificate to use for HTTPS traffic.

Load Balancing HTTPS Certificate

The certificate to use for HTTPS traffic. If you don’t have a certificate, you can create one in the

Health Check Path

The path to use for health checks on tasks connected to HTTP/HTTPS load balancers. This path will be requested by the load balancer to determine if the task is healthy. If the task returns a 2xx response, it is considered healthy. If the task returns a 4xx or 5xx response, it is considered unhealthy. Unhealthy tasks are restarted automatically.

Always use a leading / for the path. For example, /health.

Autoscaling

Determines how triggers autoscaling events are triggered.

Strategy choices are Target CPU or Target Memory to target either a CPU or Memory threshold. Beaker Studio will automatically scale the number of tasks up or down to maintain the target percentage, up to the specified maximum.

The minimum number of tasks is determined by the Instance Count parameter. The maximum number of tasks must be higher than the minimum.

CDN

Whether to provision a CloudFront CDN for the service. If enabled, Beaker Studio will automatically create a CDN and route traffic to the service’s load balancer.

For pricing, see Amazon’s CloudFront pricing.

CDN Cache

A list of paths to cache on the CDN. The TTL is the amount of time to cache the path for.

Do not add a slash / at the end of the path.

Path accepts patterns. For example, *.gif will match all files with that extension. For more information on path patterns, see Amazon’s path pattern documentation.

The cache may be invalidated from the CloudFront admin.

Environment Variables

Reference: Environment Variables.

Network Ingress

Reference: Ports.

Volumes

Reference: Volumes.