Deploying Kanject BaaS
Kanject BaaS modules deploy into your AWS account, not ours. Each module ships as one or more NuGet packages plus a CloudFormation template; you provision them once per environment and your service code talks to them like any internal dependency.
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.
- Understand the BaaS model — modules deploy into your AWS account, billed by AWS
- Provision a module with
kanject baas deploy <module> - Register it with the module's own extension and inject its service interface(s)
- Compose multiple modules in one service
Workflow
Provision the modules you need
Each module is a CloudFormation stack in your AWS account, named <stage>-<service>-<module>. The CLI wraps the deploy:
# One-time, per AWS account, per stage. Idempotent — safe to re-run.kanject baas deploy identity --env devkanject baas deploy notifications --env devkanject baas deploy wallet --env dev 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.)builder.Services.AddCognitoIdentityProvider<IdentityDbContext, AppUser, AppUserGroup>( o => { o.Region = region; o.UserPoolId = poolId; o.ClientId = clientId; });builder.Services.AddNotificationHubServer(o => { o.Region = region; });builder.Services.AddKanjectWallet<AppWalletDbContext>(o => { o.Region = region; });var app = builder.Build();app.Run(); 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 nine modules
Each card opens that module's developer guide. GA modules first, then the two in private beta.
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.
- Each BaaS module is a CloudFormation stack in your account — no per-request Kanject charges.
kanject baas deploy <module>provisions; each module registers with its own (provider-versioned) extension + typed options.- There is no unified client — inject each module's own service interface (
IUserIdentityService,ITransactionManager,IHubIngestionManager, …). - Pick a module above to go deep — Wallet, Identity, NotificationHub, and more.