Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.glue.wtf/llms.txt

Use this file to discover all available pages before exploring further.

Glue is designed to feel like normal TypeScript development: you edit code locally, your Glue hot reloads, you trigger real events, and you debug with your editor (or console.log) like any other program.

​
Your environment

​
The Glue CLI

The glue command powers local development (glue dev), deployment (glue deploy), and monitoring (glue logs, glue describe). Follow the install steps in the Quickstart:

​
Editor

The beauty of Glue is that you bring your own editor. All the tooling you’re normally used to just works. For best results, make sure to use an editor that supports TypeScript and Deno so that you get autocomplete, formatting, linting, etc. Here are instructions for setting up your editor for Glue:

​
Use your favorite LLM

LLM’s can write Glue code really well. The Glue runtime is fully documented with TSDoc and this documentation site has a LLM friendly single markdown file for the entire site.

​
Running your Glue locally

You can run a Glue locally so that you can have a fast iteration loop. When running Glues locally, you receive real events from the triggers you’ve registered. Our Glue servers register and listen for these events and will tunnel them to your local machine when you are running your Glue locally using glue dev. 
glue dev path/to/your-glue.ts
For example, if you’ve registered a trigger that listens for new emails in your Gmail inbox, when an actual email hits your inbox, we’ll tunnel that real event to your locally running Glue so you can test with real data. What glue dev actually does:
  • Runs your Glue locally in a watched process so that code changes are hot reloaded.
  • Registers your Glue + triggers with Glue’s backend so trigger events can be routed to you.
  • Streams trigger events to your local machine.
  • Opens a debugger port by default so you can attach a debugger.

​
Sample Events

The best “sample event” is a real event. If you’ve registered a webhook trigger, simply visit or cURL the URL that glue dev prints out so that you can see the real event data. If you’ve registered a trigger to listen for new emails in your Gmail inbox, simply send an email to that address. The only exception is for CRON triggers which you can trigger manually in the CLI when using glue dev. There is no support for generating fake data, we think that is an anti-pattern. However, we do provide helpers to let you replay real events to make iterating and testing fast.

​
Replay the last event (fast loop)

While glue dev is running, you can iterate extremely quickly:
  • Write your Glue code
  • Run glue dev
  • Trigger the event manually in whatever service you registered a trigger for
  • Edit your code (it’ll hot reload on save)
  • Return to the glue dev terminal
  • Press r to replay the last trigger event you received
  • Repeat
This makes it easy to run the same event through your updated code without re-triggering the external system.

​
Replay a production event

If you’ve deployed your Glue to production, you can replay a specific event by ID. This is useful for debugging production issues or for testing your Glue against real data. 
glue dev --replay <executionId> path/to/your-glue.ts
This will start your Glue locally and immediately replay the event you specified. This lets you test or debug a production issue locally. Even better, once you find the issue, you can modify your code, hot reload it, then press r to replay the event again and test your fix.

​
Debugging

Glue doesn’t require special debugging tooling, you can:
  • Use console.log like you would in any TypeScript program.
  • attach a Chrome DevTools debugger to your local Glue process
  • attach your editor debugger (if supported)
By default, glue dev runs your Glue with the debugger enabled. It prints out the debugger URL to connect to: 
glue dev path/to/your-glue.ts
Output: 
EXAMPLE HERE
You can disable the debugger with --no-debug. If you want your Glue to wait until your debugger is attached, start dev with: 
glue dev --inspect-wait path/to/your-glue.ts

​
Deploying and monitoring

Deployment is a single command that takes your locally running Glue, bundles it, uploads it, sets up the same triggers (including webhooks) and hosts your Glue in the cloud: 
glue deploy path/to/your-glue.ts
To deploy an update, simply run glue deploy again. Glues with the same name are treated as an update.

​
Monitoring Glues

Glue creates a new execution every time your Glue runs. Each execution has a unique ID and its own log lines (including your console.logs). A failure is simply an execution where your Glue throws an exception. You can monitor these executions in several ways:

​
Aggregate stats about all Glues

glue describe <glue-name-or-id>
This tells you how many times your Glue has run, how many times it has failed, when it was last run and more info about its history. You’ll also get a daily email summary for all your Glues with these same statistics. You may also want to watch events as they happen and see their output: 
glue logs --tail <glue-name-or-id>
You can run this command without the --tail flag to see historic executions. By default, this will only show the first few lines of output for each execution. You can control this and other options, see the glue logs reference for more details.

​
Viewing specific executions

glue describe <execution-id>
This will show you the input data that triggered the event, the timestamp, the run time, the status and any console logs outputted by your Glue.

​
Versioning and sharing your Glues

Every deploy creates a new immutable deployment. Subsequent deployments override the previous deployment and you can see a history of all your deployments with glue describe. Since a Glue is just a single TypeScript file, you can version and share it like any other file:
  • Put it in a Git repo
  • Share it as a Gist (try glue share path/to/your-glue.ts)
  • Send it over Drive, email, etc.
It’s important you do not hardcode account credentials in the Glue itself (or in an .env file). Use the runtime provided triggers and account fetchers instead. Doing so will let others run your Glue, and Glue will ask them to authenticate with their credentials.