Go Tables
The table declaration is a design act the Go code then trusts: key_name and sortkey_name encode the access patterns (orders by customer, newest first), and secondary indexes declare the second read honestly. Seed files at seed/tables/orders.json make local serves and previews start from representative data.
Inside deployed functions and workers, the SDK client is built from the injected access key set (KERNSTACK_ACCESS_KEY_ID, KERNSTACK_ACCESS_KEY_SECRET, KERNSTACK_DZONE) — the same code runs locally with your own key set, so there is no environment-specific credential plumbing to maintain.
Writes can announce themselves: add change_stream to the table and a Go function receives batched change records. The pair (Go handler, streamed table) covers a large share of event-driven product backends without a queue product entering the picture.
CLI
Plan Go Tables, then deploy.
kernstack add function --name api --blueprint func-go-minimal
kernstack plan
kernstack deploy Frequently asked questions
With an access key set passed to the typed client. In deploys the platform injects the key set as environment variables; locally you supply your own. Keys never live in source.
The table’s storage at 0.04 credits per GB-hour, plus the GiB-seconds of the Go code doing the reading and writing. There are no per-unit read/write meters to model.
Yes. Binary workers use the same SDK and the same declarations; the function/worker choice is about duration and triggers, not about data access.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.