okuri

Quickstart

The repository ships a Compose file that brings up a complete local stack: okuri, MinIO as the object store, a bucket bootstrap job, and a readiness probe.

git clone https://github.com/okuri-oss/okuri
cd okuri
docker compose up -d --wait

When --wait returns, okuri is serving its API on localhost:8080 and its admin endpoints on localhost:9090.

Drive it with the AWS CLI

The compose stack ships fixed development credentials, so the stock AWS CLI works as-is:

export AWS_ACCESS_KEY_ID=AKIDOKURICOMPOSEDEV
export AWS_SECRET_ACCESS_KEY=b2t1cmktY29tcG9zZS1kZXYtc3FzLXNlY3JldA==
export AWS_DEFAULT_REGION=us-east-1

Create a queue, send a message, receive it back:

QUEUE_URL=$(aws sqs create-queue --endpoint-url http://localhost:8080 \
    --queue-name jobs --query QueueUrl --output text)

aws sqs send-message --endpoint-url http://localhost:8080 \
    --queue-url "$QUEUE_URL" --message-body 'hello from okuri'

aws sqs receive-message --endpoint-url http://localhost:8080 \
    --queue-url "$QUEUE_URL"

Any SQS SDK works the same way: point its endpoint at http://localhost:8080 and keep the rest of your code unchanged. boto3, aws-sdk-js, aws-sdk-go, Celery, and Laravel queues are all exercised in CI.

The credentials above are fixed dev values baked into compose.yaml for the local stack only. Never reuse them anywhere real.

What the stack contains

service role
minio S3-compatible object store on :9000, console on :9001
mc one-shot job that creates the okuri-dev bucket
okuri the server, API on :8080, admin on :9090
okuri-ready health probe polling http://okuri:9090/readyz

Next