@turjuman/aws-cdk
v0.2.0
Published
Turjuman AWS CDK construct: a composable serverless stack (single-table DynamoDB + Lambda Function URLs) with pre-bundled handlers.
Maintainers
Readme
@turjuman/aws-cdk
AWS CDK construct for Turjuman — the self-hosted, MCP-driven translation backend as a composable, props-driven stack.
It declares the whole topology: the retained single-table DynamoDB store (PK/SK +
GSI1/2/3 + Streams) and up to three Lambda Function URLs — the always-on MCP
server, the optional REST API (for the developer CLI/CI), and the optional
DynamoDB Streams → webhook dispatcher. The Lambda code ships pre-bundled
inside @turjuman/mcp-server and @turjuman/api, so the construct needs no
build step of its own.
Most self-hosters never touch this directly — they run
@turjuman/aws-deploy,
the one-command CLI that deploys this construct (and self-bootstraps the CDK
environment). Reach for @turjuman/aws-cdk when you want to compose Turjuman into
your own CDK app.
Usage
import { App } from "aws-cdk-lib";
import { TurjumanStack } from "@turjuman/aws-cdk";
const app = new App();
new TurjumanStack(app, "Turjuman", {
// every option is optional; defaults reproduce the standard stack
table: { pointInTimeRecovery: true, deletionProtection: true },
webhook: { enabled: false }, // drop the webhook surface
});Or drop the reusable construct into an existing stack:
import { Turjuman } from "@turjuman/aws-cdk";
const turjuman = new Turjuman(this, "Turjuman", { corsAllowOrigins: ["https://example.com"] });
turjuman.mcpUrl.url; // exposed for outputs / wiringThen cdk deploy in a bootstrapped account (cdk bootstrap once per
account/region). aws-cdk-lib and constructs are peer dependencies — you own
the CDK version.
Options
See TurjumanProps / TurjumanStackProps. Highlights: table (billing mode,
provisioned capacity, point-in-time recovery, deletion protection), per-function
architecture/memorySize/timeout (via functionDefaults, mcp, api,
webhook), corsAllowOrigins, vpc, and api/webhook enabled toggles.
Defaults reproduce the on-demand, streamed, retained single-table topology.
The DynamoDB table is declared with RemovalPolicy.RETAIN and a deliberately
fixed construct id, so a refactor can never make CloudFormation replace (and thus
wipe) your data.
