SDK

Official libraries for calling JustDeploy from the code you deploy. They cover your database, your files, and sending email, and a deployed app needs no keys at all: JustDeploy puts an identity in the image and the library uses it.

They are for server code. If you are only deploying an app and not calling JustDeploy from inside it, you do not need any of this.

Install

npm install @justdeploy/sdk@0.1.1

python -m pip install justdeploy-sdk==0.1.1

The Python package installs as justdeploy-sdk and imports as justdeploy. Both are published from our own repository and carry the same version.

How it signs in

Construct the client with no arguments. There is no API URL, no key, and no configuration file to pass.

import { JustDeploy } from '@justdeploy/sdk'

const justdeploy = new JustDeploy()
const result = await justdeploy.databases.query('your-database-id', 'SELECT * FROM orders')

from justdeploy import JustDeploy

with JustDeploy() as justdeploy:
    result = justdeploy.databases.query("your-database-id", "SELECT * FROM orders")

Python also ships AsyncJustDeploy with the same methods, awaited.

It looks in one fixed order:

• Both JUSTDEPLOY_ACCESS_KEY and JUSTDEPLOY_SECRET_KEY in the environment: it trades them for a short-lived session. This is how you run the code on your own machine.
• Otherwise the deployment identity JustDeploy adds while building. This is the path for a deployed app, and it needs nothing from you.
• Neither one present: it stops with an authentication error rather than guessing.

One variable set without the other is an error, and a rejected key never quietly falls back to the deployment identity. An app that already has keys registered keeps using them, and nothing about your build changes if you leave them in place.

What you can call

Three areas, named the same way in both languages. Python method names are in snake case, so listTables is list_tables.

justdeploy.databases.list()
justdeploy.databases.query(databaseId, 'SELECT * FROM orders')
justdeploy.databases.listTables(databaseId)
justdeploy.databases.createTable(databaseId, { ... })
justdeploy.databases.updateTable(databaseId, 'orders', { ... })
justdeploy.databases.deleteTable(databaseId, 'orders')

justdeploy.storages.list()
justdeploy.storages.upload(storageId, { ... })
justdeploy.storages.listFiles(storageId, { limit: 50 })
justdeploy.storages.getFile(storageId, fileId)
justdeploy.storages.download(storageId, fileId)
justdeploy.storages.deleteFile(storageId, fileId)

justdeploy.mail.send({ ... })
justdeploy.mail.list({ limit: 50 })
justdeploy.mail.get(mailId)

Two things behave differently from what the shapes suggest. query takes data statements only, so use the table methods to change a schema. And an upload gives you a file id, not a lasting URL: store the id, then call getFile when you need a fresh link.

Pass an idempotencyKey when sending email if a retry is possible, and remember that a successful send means accepted rather than delivered. Read status back later if delivery matters.

When a call fails

Every failure is a JustDeployError. An error from the API carries status, retryAfter, requestId, and details, which is enough to decide whether waiting helps. Your request body, your SQL, your file contents, and your keys are never kept on the error, so it is safe to log the error itself.

What it does not cover

• Server code only. Not browsers, not edge runtimes, not Deno or Bun. A key in browser code is a key you have given away.
• Node.js and Python only. For anything else, call the API with the header described in Authentication.
• Database, files, and email. Builds, projects, logs, and everything else stay on the API.
• No command line tool, and no way to send an arbitrary request to a URL of your choosing.

Presigned uploads and downloads never carry your credentials, so a file transfer cannot leak them. Asking for a file whose upload is still finishing gives you a retry-later error rather than a half-written response. See Authentication for the raw header, and Credentials for managing keys.