Managed by us, or inside your environment.
Kelynto is one codebase with two ways to run it. This page says what runs where, what crosses the boundary in each model, and how far each path has actually been proven. Azure first.
Two deployment models.
The same container images in both. The difference is whose cloud account they run in, and who operates them.
Kelynto Managed
In the Kelynto Managed model your data is stored and processed in Kelynto's Microsoft Azure subscription, in one region, separated from other customers in the application and again in the database. Store coordinates are sent to public weather services. A language model receives your weekly facts only if your administrator enables it.
- Status today: Designed and rehearsed, not yet running. No hosted service exists today.
- What you provide: a weekly file or a scheduled export, and the details of your identity provider.
- Until it runs: a pilot can start with files exchanged by hand. You send the week's file and we return the drafted review.
Customer Environment
Kelynto can run inside your own cloud account. In that model your sales, plan and in-stock data, your store list and your users' details are stored and processed in your environment and are not sent to Kelynto. The software does not call home.
- Status today: Available through enterprise implementation. The deployment kit for Azure is built and validated statically; it has not yet been deployed to a live subscription.
- The first install is done alongside your IT team and treated as the validation run.
- What you provide: a resource group, an application registration in your directory, a host name in your DNS zone, and a mailbox for alerts.
- You decide who holds owner access, who receives alerts, and who may open a shell in the containers.
What runs where.
The same components in both models. The database is the only state; everything else is rebuilt from the release.
| Component | Kelynto Managed | Customer Environment |
|---|---|---|
| Web app, API and scheduler | Containers in Kelynto's Azure subscription | The same containers in your Azure subscription |
| Database | Azure Database for PostgreSQL, shared by tenants and separated by row-level security | Azure Database for PostgreSQL in your subscription, one tenant |
| Secrets | Key Vault in Kelynto's subscription | Key Vault in your subscription |
| Sign-in | Your identity provider. A shared provider exists for customers without single sign-on | Your identity provider |
| Logs and alerts | Log Analytics in Kelynto's subscription | Log Analytics in your subscription |
| Backups | The PostgreSQL service's backups, in Kelynto's subscription | The PostgreSQL service's backups, in your subscription |
| AI writer, if an admin turns it on | The provider the admin chooses | Azure OpenAI in your own tenant is supported |
What crosses the boundary.
Your data does not have to leave your environment. By default Kelynto looks up weather for your stores by sending their coordinates (no names, no sales) to two public weather services. You can switch that off, for one workspace or for the whole deployment with a setting no workspace administrator can change. With it off and the standard template writer, the only outbound connection is to your own identity provider, to download its public signing keys.
Optional features send data out only when you switch them on: an event source receives store coordinates, and a language model writer receives the week's aggregated facts, including store names and amounts. A deployment-level setting can forbid both for every workspace.
| Flow | What is sent, and where | Control |
|---|---|---|
| Your weekly files | Weekly totals by store and category, sent to the upload endpoint. In the Customer Environment model they never leave your subscription. In the Managed model they go to Kelynto's service. | Totals only. No transactions, shopper, payment or employee data is needed. |
| Sign-in | The browser goes to your identity provider. The API downloads your provider's public signing keys. Nothing about your data is sent. | Your identity provider enforces multi-factor sign-in and conditional access. |
| Weather | Store coordinates, rounded to four decimals, and a date range, sent to Open-Meteo and the National Weather Service. No store names and no sales. The National Weather Service asks every caller for a contact in a request header; in a Customer Environment you set your own, and none is sent that names Kelynto unless you set it. | On by default. Each source can be switched off per workspace, and all outbound lookups can be switched off for the whole deployment. |
| Local events | Store coordinates, a radius and a date range, sent to PredictHQ. | Off unless an admin enables the source and the deployment holds a key for it. Forbidden for every workspace when the deployment-level setting is off. |
| Road work | Nothing is sent. State road-work feeds are downloaded and matched to stores inside the deployment. | Off until an admin lists a feed. Addresses must be public https addresses. |
| AI writer | The week's aggregated facts, including store names and amounts. Never raw rows or user details. | Off by default. An admin must turn it on and choose the provider. A deployment-level setting can forbid it for every workspace. |
| The browser | The web app loads its fonts and scripts from its own origin and calls no third-party origin except the identity provider chosen at sign-in. | Enforced by the app's Content Security Policy. |
| Telemetry | None. The software does not call home: no usage telemetry, no licence check, no update check and no error-reporting service. | Checked by reading the code, not by watching a network. |
| Deployment-level settings | Nothing is sent. Two settings on the deployment forbid every outbound signal lookup and every call to an external language model, for every workspace. The settings screen shows them as locked and the onboarding check reports them. | Set by whoever runs the deployment. A workspace administrator cannot change them. Exercised by automated tests, not observed on a network. |
| Kelynto staff | In the Customer Environment model, whether Kelynto staff have any access to your subscription is agreed in the contract. | You hold the subscription. |
In both models: Kelynto does not need or store shopper, payment or employee data. It works on weekly sales and plan by store and category. AI text generation is off by default. The weekly commentary is written by a deterministic template unless an administrator switches a language model on.
Azure first.
Azure is the design target, and the only cloud whose templates are complete and documented.
- Azure Container Apps for the web app, the API and the scheduler. The API has internal ingress only.
- Azure Database for PostgreSQL with no public endpoint, in a delegated subnet.
- Key Vault for secrets, read through managed identities. No secrets in code, parameters or images.
- Log Analytics for container, database and Key Vault logs, with email alerts.
- Optional Front Door with a web application firewall in front.
Other paths.
Stated so you do not have to ask.
- A single virtual machine with Docker Compose. The same images, for a small install. Rehearsed on a development machine.
- AWS. Available through enterprise implementation. A Terraform module for AWS (ECS on Fargate, RDS for PostgreSQL) is written and checked statically; it has never been planned or applied against an AWS account. A first install would be the validation run.
- Google Cloud. No templates, documentation or testing. Not available.
- Your own data center. No on-premises product was packaged or tested. There is a container path for any Docker host with PostgreSQL, as an implementation project.
Sign-in, roles and tenant isolation are in the Trust center.
How far each path has been proven.
Nothing has run against a live Azure subscription or a real identity provider yet. This is the record of what was executed, and what was not.
| Part | Proven by running it | Not yet proven |
|---|---|---|
| Container stack | Run in production mode on a development machine: database bootstrap, migrations, a smoke test, a full customer onboarding, isolation checks through the API and at the database, and container lock-down. | The run used local stand-ins for the public base images, which that machine could not download. The real images are validated by the first build that can pull them. |
| Azure templates | They compile and lint cleanly. | Applying them. Private networking, Key Vault references, ingress, alerts, Front Door and point-in-time restore are checked only by Azure itself. |
| Sign-in | Exercised end to end against a mock identity provider, including tokens that must be refused. | A browser signing in at a live Entra ID, Okta or Auth0 tenant. |
| Backup and restore | One drill of the single-VM procedure, locally, on a small synthetic database. | A restore on Azure. Recovery times are targets, not measurements. |
| Outside signals and AI providers | Covered by automated tests, with the outside services simulated. | Calls to the live services from a deployed environment. They were switched off in the deployment rehearsal. |
| Scale | Ingest, the weekly run and read latency were measured at 500 and 2,000 stores on a small development machine, with synthetic data. | Production hardware, and many large tenants in one database. |
What your IT team would do.
For a Customer Environment install. This is a planning outline: no customer has gone through it yet.
- Review Read the Trust center and the security overview. Ask for the review pack.
- Register the application In your identity provider, with the roles viewer, planner, analyst and admin. This step usually sets the pace, because it follows your own change process.
- Deploy Run the templates in a resource group you own, with us alongside, or have us run them with access you grant.
- Verify Run the supplied checks: health, sign-in, security headers, and that a database connection bound to no tenant sees no rows.
- Load and run Stores first, then sales. The first week is run by hand and read together.
Deploy in your environment
- Tell us your cloud, your identity provider and your review process
- We answer in writing where the answer is known, and say so where it is not
- You would be the first install, and we will not pretend otherwise