Dev Overlay

When a service is deployed and used in production, starting a second instance with the same credentials would normally enter the round-robin pool — meaning your local development instance could receive production messages. Dev overlay solves this problem.

How It Works

If a service is started with the same credentials plus a personal access token (the devToken), Requence registers it as a dev service instead of adding it to the production pool. When the same user — identified by that personal access token — starts a task via the UI or via a package, Requence will always route messages to the dev service first. This lets you test changes to your service implementation without risking production.

Setup

TypeScript

import { createService } from '@requence/service'

createService(
  {
    version: '1.0.0',
    devToken: process.env.REQUENCE_DEV_TOKEN,
  },
  (ctx) => {
    // This instance only receives messages from your own tasks
    return ctx.input
  },
)

Python

import os
from requence.service import Service

def handler(ctx):
    # This instance only receives messages from your own tasks
    return ctx.input

Service(
    {"version": "1.0.0"},
    handler,
    dev_token=os.getenv("REQUENCE_DEV_TOKEN"),
)

The dev token is resolved in the same order as the access token — config option, environment variable (REQUENCE_SERVICE_DEV_TOKEN / REQUENCE_DEV_TOKEN), or config file.

Combining with Branching

Dev overlay only affects the service implementation — the code that runs. If you also need to change the service definition (input schema, configuration schema, or outputs), combine dev overlay with branching. This way you can iterate on both the service logic and its contract without touching the published version.