Skip to content

Runtime and Infrastructure

Slingshot treats infrastructure as part of app assembly, not as scattered package-local setup.

app.config.ts
// @skip-typecheck
import { type AppConfig, defineApp } from '@lastshotlabs/slingshot';
declare const myRuntime: AppConfig['runtime'];
export default defineApp({
db: {
postgres: process.env.POSTGRES_URL,
redis: process.env.REDIS_URL,
},
upload: {
provider: 'local',
directory: './uploads',
},
jobs: {
enabled: true,
},
logging: {
enabled: true,
},
metrics: {
enabled: true,
},
observability: {
serviceName: 'slingshot-app',
},
secrets: { provider: 'env' },
runtime: myRuntime,
});

db decides how the framework resolves infrastructure for packages, entities, permissions, uploads, jobs, and more.

Secrets resolve before most of the app is assembled. That is why secrets is a top-level concern.

The runtime abstraction is part of the app root because it affects hosting, file access, and server startup behavior.

These are not package-internal details. They expose app-level infrastructure and HTTP surfaces.

logging, metrics, and observability are operational features the framework can wire once for the whole app.

Read these with the root config, not after the fact

Section titled “Read these with the root config, not after the fact”

One of the main docs goals here is to make the app root communicate production reality early:

  • what storage exists
  • what operational endpoints exist
  • how secrets are resolved
  • what runtime the app assumes

You have now seen the full app authoring surface. From here: