Deploying Kanject BaaS

Kanject BaaS modules run inside your .NET service against AWS resources in your account. Use Kanject CLI to install the private NuGet packages and deploy your service. Register each module in Program.cs and configure it to use your AWS resources.

Because the modules run in your account, there are no per-request, per-user, or per-message Kanject charges. AWS bills you the same as if you'd written the integration yourself — Kanject only charges for the libraries.

How it works

Get the packages and templates

You need an AWS account you control, Kanject CLI, and customer access to [developer.kanject.cloud](https://developer.kanject.cloud). BaaS libraries are private NuGet packages installed using Kanject CLI. Follow your customer installation instructions for feed access and the packages required by your selected module and provider version.

CloudFormation templates are available separately to customers through [developer.kanject.cloud](https://developer.kanject.cloud); they are not bundled with the NuGet packages. Obtain the template for your module and follow its configuration instructions before deploying your service.

Provision the AWS resources

Use the customer CloudFormation templates to prepare your infrastructure. The module-specific setup options below explain which resources can also be created at runtime and which must exist before your service starts:

• The module creates them. With its setup switch on, a module creates its DynamoDB tables, indexes, and SQS queues if they don't exist yet — Setup on NotificationHub and InstantMessaging, EnableSetup on Insights and EventHub. Wallet always creates its SQS queues if they're missing, and FileServer creates its S3 bucket (private, bucket-owner-enforced) if there isn't one by that name.
• The module syncs them. EventHub creates an SNS topic for each registered event topic when SyncEventTopics is on. InstantMessaging's API Gateway chat hub creates its WebSocket API unless you set DisableCreateWebsocket and pass an existing one.
• You create them. Identity's Cognito user pool and its app clients — the module reads them by ID (UserPoolId, ClientId) and never creates them — and Wallet's ledger table, which the released package doesn't create. Provision them using the customer CloudFormation templates, your own infrastructure-as-code, or the AWS console.

Register them in your service

There is no single AddKanject<Module> convention — each module exposes its own registration extension (from a provider-versioned namespace) that takes a typed options delegate. Composition is order-independent:

using Kanject.Identity.Provider.AwsCognitoV4.Extensions;using Kanject.NotificationHub.Provider.AwsV2.Extensions;using Kanject.Wallet.Extensions;​var builder = WebApplication.CreateBuilder(args);​// Each module has its OWN registration extension + typed options delegate.// (Provider-versioned packages — pick the provider version you target.)// AppIdentityDbContext derives from IdentityDbContext<AppUser, AppUserGroup>.builder.Services.AddCognitoIdentityProvider<AppIdentityDbContext, AppUser, AppUserGroup>(o =>{    o.Region = region; o.UserPoolId = poolId; o.ClientId = clientId;    o.IdentityDynamoDbConfig = identityTable;   // the identity data store});​builder.Services.AddNotificationHubServer(o => { o.AwsRegionEndpoint = region; });​builder.Services.AddKanjectWallet<AppWalletDbContext>(o => { o.Region = region; });​var app = builder.Build();app.Run();

Deploy with Kanject CLI

Once the private packages are installed, the module is registered, and its AWS resources are configured, deploy the service using Kanject CLI. For a Lambda service, run these commands from the initialized service project after configuring its dev stage and artifact bucket:

kanject doctor --env devkanject aws deploy --env dev

The Lambda quick start covers project initialization, stage configuration, and the artifact bucket. The deployment guide explains deployment and rollback; use ECS Fargate for a container-hosted service. Follow the customer template instructions for the infrastructure required by your module.

Use them anywhere

Each module has its own service interface — IUserIdentityService<…>, ITransactionManager, IHubIngestionManager, and so on. Inject the ones you need:

// Inject each module's own service interface — there is no single unified// client; every module exposes its own typed surface.public class CheckoutService(    IUserIdentityService<AppUser, AppUserGroup> identity,    ITransactionManager transactions,    IHubIngestionManager notifications){    public async Task CheckoutAsync(PostingEvent paymentEvent, string email)    {        await transactions.PostTransactionAsync(paymentEvent);   // Wallet        await notifications.IngestContentNotificationAsync(       // NotificationHub            new IngestContentNotificationRequest            {                To = email, Subject = "Order confirmed",                Body = "Thanks for your order.",                Channel = PublishChannel.Email,            });    }}

The ten modules

Each card opens that module's developer guide. GA modules first, then the three in private beta. Workflow hasn't shipped yet, so its card opens the product page; the guide arrives with the release.

Bring-your-own delivery providers

NotificationHub ships AWS-native defaults but every channel is pluggable — implement IHubDispatchProvider and mark it [NotificationPublisherProvider] to add a delivery channel or swap a provider. The engine still owns scheduling, priority, and cancellation; the wire stays in your hands.