Build runtime config

When to use

taubyte-go-sdk-constraints

How builds are triggered

1. Resource code and config are pushed to GitHub (normal

   git push

   workflow for the function, website, or library repo as appropriate).
2. Remote cloud
   After the push, the cloud is reached from GitHub (webhook). Builds trigger automatically — no extra inject step on your machine.
3. Local Dream
   GitHub cannot call into your laptop, so webhooks do not drive Dream the same way. After pushing to GitHub you must trigger the build from the local machine using Dream inject:

   Command	Use for
   dream inject push-all	Config and code for the whole project — run from the project root ( --path = absolute project root).
   dream inject push-specific	Individual resource repos that need their own inject after a full sync — e.g. libraries and websites (per-resource repo path and identifiers).

   Always run

   push-all

   successfully before

   push-specific

   when both apply. Universe, Docker, and flag details (e.g.

   --rid

   ,

   --fn

   for websites) live in

   taubyte-dream-local-operations

   .

Targets

• Function:

  <project>/code/.../functions/<name>/.taubyte/

• Website repo:

  <project>/websites/tb_website_<name>/.taubyte/

• Library repo:

  <project>/libraries/tb_library_<name>/.taubyte/

Required checks

1. .taubyte/config.yaml

   exists and is valid (image, workflow, etc. — not runtime env var declarations).

2. .taubyte/build.sh

   exists, is non-empty, writes output Taubyte expects (e.g. function wasm + ret-code, website assets under

   /out

   ).
3. Runtime env vars (if any) are set in

   .taubyte/build.sh

   (e.g.

   export …

   before build steps), not in

   config.yaml

   .

Function

config.yaml

pattern

version: 1.00
environment:
  image: taubyte/go-wasi:latest
workflow:
  - build

config.yaml

Function

build.sh

pattern

#!/bin/bash
. /utils/wasm.sh
# Runtime env for this build (example — use real names/values your code expects):
# export MY_VAR=value
build "${FILENAME}"
ret=$?
echo -n $ret > /out/ret-code
exit $ret

Website

build.sh

(technology-specific)

build.sh

package.json

dist/

build/

• Produce a non-empty

  /out

  (Taubyte’s deploy staging path inside the build environment — not the same as a framework’s own

  out

  folder name on disk).
• Put build-time env here with

  export

  , not in

  config.yaml

  .

package.json

scripts.build

/out

• Plain static (no bundler):
  bash

  #!/bin/bash
  cp index.html /out/

• Vite (default output

  dist/

  ):
  bash

  #!/bin/bash
  npm ci
  npm run build
  cp -r dist/* /out/

• Create React App /

  react-scripts

  (output

  build/

  , not

  dist/

  ):
  bash

  #!/bin/bash
  npm ci
  npm run build
  cp -r build/* /out/

• Other stacks (Next, Nuxt, custom webpack, etc.): run that project’s install + production build commands, then

  cp -r <framework-output-dir>/* /out/

  using the directory that tool actually generates (check docs and a local build once if unsure).

Rules

• Env vars: declare and use them in

  .taubyte/build.sh

  only; do not put runtime env declarations in

  .taubyte/config.yaml

  for this purpose.
• Websites: tailor

  build.sh

  to the actual framework and build output (e.g. Vite →

  dist/

  , CRA →

  build/

  ); never copy a Vite-only script onto a React-CRA repo without changing paths and commands.
• Do not push to GitHub before validating

  .taubyte/build.sh

  and

  .taubyte/config.yaml

  .
• After changing build/config, remote cloud: rely on webhook-driven builds after push; Dream: run

  dream inject push-all

  and, for website/library resource repos,

  dream inject push-specific

  as required, then verify logs/build per

  taubyte-push-build-verify

  .
• Document notable env or build assumptions in the context log (

  taubyte-context-log

  ).
• For Go compile issues, validate handler code against

  taubyte-go-sdk-constraints

  .