Services

Service Components are used for running web servers. Typically, they are responsible for responding to traffic from the public internet, but they can also be used to run private APIs.

A Service can run a web server or microservice in any programming language or framework. Noop supports all container images. Popular examples of Service runtimes include:

• Node.js
• Ruby
• PHP
• Golang
• Java
• Python

Service Configuration

Service defaults are configured in your Blueprint Manifest (blueprint.yaml). Memory and CPU capacity, build process, and runtime details are all defined in blueprint.yaml.

Here is a basic example of a Node.js service with no runtime variables:

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    runtime:
      command: npm start

Routing Traffic to a Service

By default, Services are not accessible via the public internet. In order for clients to connect to your Services, you need to set up an Endpoint and a Route.

Endpoints are defined in the console and target a specific Environment. Once traffic requests are forwarded from the Endpoint to your Environment, the Routes defined in your Blueprint Manifest (blueprint.yaml) are used to determine which Component should handle that request.

Assuming an Endpoint is already created, the following blueprint.yaml will send all traffic to the ExampleService component:

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    runtime:
      command: npm start
routes:
  - target:
      component: ExampleService

Connecting to a Resource

Noop automatically manages the variables used for Resources. To associate a Service with a Resource, include the Resource name in the Service’s runtime.resources property in blueprint.yaml. Here is an example of a Service that uses a MySQL Resource and surfaces the URL as a variable in the Service runtime:

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    runtime:
      resources:
        - ExampleDB
      variables:
        dbUrl:
          $resources: ExampleDB.url
resources:
  - name: ExampleDB
    type: mysql

Scaling and Sleep Settings

Service sleep and target instance count are environment-specific properties, defined in the Noop Console. To set these properties, go to the Service scaling page under the Environment’s Stack settings in the Noop Console.

Service sleep indicates whether the Service should be turned off unless it receives traffic. When a Service is set to sleep, a time duration is provided. If the Service does not receive traffic for a duration longer than the specified value, it will turn off. The Service will wake up when traffic resumes. Production Environments are configured not to sleep, while non-production environments go to sleep by default. These defaults can be changed for both production and non-production Environments.

Also on the Service scaling page is the target instance count. Increasing the instance count above 1 provides redundancy and increased capacity. The default target instance count is 2 for production Environments and 1 for non-production Environments. Once the Service is deployed, Noop will automatically scale to the target instance count.

Services need to be designed to relaunch predictably. This is because the containers responsible for running a Service are occasionally replaced. Noop will ensure there is no disruption while replacing the containers, but any filesystem and memory state used by the Service will be lost.

Configuration Reference

Service Components are defined in your .noop/blueprint.yaml as an array under the components property.

• The name property is an alphanumeric string and is required.
• The type property is required and must be set to service.
• The image property is the name of the container image. Noop supports Docker Hub images. This property is required.
• The build property describes an array of steps to follow while building the Service.
• The runtime property describes properties for how the Service should be executed.
• The port property specifies which TCP port the Service listens to for HTTP traffic. Default: 80.
• The health property specifies how to evaluate the health of a Service instance.
  • health.checker can be set to http, tcp, or cmd.

blueprint.yaml Examples

Basic Service

components:
  - name: ExampleService
    type: service
    image: node:24-alpine

Service with Build Steps

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    build:
      steps:
        - copy: package*.json
        - run: npm ci
        - copy: .
        - run: npm test

Service with Runtime Configuration

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    runtime:
      command: npm start
      variables:
        log_level: info
      cpu: .5
      memory: 512

Service Using a MySQL Resource During Runtime

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    runtime:
      resources:
        - ExampleDB
      variables:
        dbUrl:
          $resources: ExampleDB.url
resources:
  - name: ExampleDB
    type: mysql

Service with Other Options

components:
  - name: ExampleService
    type: service
    image: node:24-alpine
    port: 8080
    health:
      checker: http
      path: /_health