Key takeaways

• Learn how to connect ToolJet to AWS services like Amazon S3 and Amazon DynamoDB using secure authentication methods such as IAM access keys, instance profiles, and ARN roles.
• Configure Amazon S3 as a ToolJet data source to build internal file explorers, document management systems, and upload workflows with signed URL support.
• Integrate Amazon DynamoDB with ToolJet to query, scan, update, and manage NoSQL data for operational dashboards and CRUD applications.
• Follow AWS security best practices including least-privilege IAM policies, instance roles, credential rotation, and private network access for production deployments.
• Compare common AWS services including S3, DynamoDB, Lambda, Redshift, Athena, SES, Textract, and Bedrock to choose the right backend for your internal tools.
• Discover how ToolJet’s native AWS connectors simplify building self-hosted internal applications without writing extensive frontend code.
• Build secure, scalable AWS-powered internal tools faster by combining ToolJet’s low-code platform with your existing AWS infrastructure.

ToolJet is a self-hosted internal platform built for teams who need to expose or edit data that already lives somewhere else. And for a lot of engineering teams, that somewhere else is AWS. This guide walks through connecting ToolJet to Amazon S3 and Amazon DynamoDB, the authentication options you’ll choose between, and the security habits worth locking in before you ship anything to production.

ToolJet doesn’t copy your AWS data into another database. Instead, it connects directly to AWS services using the authentication method you configure, executes queries on demand, and displays the results inside your application. Your AWS infrastructure remains the source of truth while ToolJet provides the interface.

Every AWS data source in ToolJet uses roughly the same four authentication options. So it’s worth understanding them once, rather than relearning them every time you add a new connector.

Here is what to evaluate before picking one:

• IAM access keys for quick setup
• Instance profiles for EC2 or ECS
• ARN role assumption for cross-account access
• Scoped permissions, never root credentials

IAM access keys are the simplest option. You supply an access key ID and secret for an IAM user, and that’s it. Good for local development, or for any deployment where ToolJet isn’t running inside AWS already. Instance credentials work differently. If ToolJet runs on an EC2 instance or an ECS task with an IAM role attached, it uses that role directly instead of static keys, which means no long-lived secrets sitting in your configuration.

ARN role assumption is the one you reach for when ToolJet needs to access a resource in a different AWS account, or when your org wants permissions centralized in one place rather than scattered across IAM users. As a general rule, use IAM keys while you’re prototyping, and move to an instance profile or ARN role before anything touches production. And whichever method you pick, create a dedicated IAM identity scoped to exactly what ToolJet needs. Never reuse a personal or root AWS account for this.

Not sure this is worth the setup time? See how ToolJet’s data sources work across 80-plus connectors before you commit to a stack.

[Figure 1: Go to console]

S3 is the obvious pick when your internal tool needs to upload, browse, or manage files. Document repositories, media libraries, and content review tools all lean on it.

What you need before connecting S3:

• An AWS account with console access
• A bucket already created
• A dedicated IAM user for ToolJet
• Region, access key, and secret key
• A custom endpoint if self-hosted

Start in the AWS console. Create a bucket if you don’t have one yet, name it something your team will recognize later, and leave the default region unless you have a reason to change it.

[Figure 2: Create an S3 bucket]

From there, set up IAM credentials scoped to that specific bucket. This is the step people skip, and it’s the one that matters most. Don’t hand ToolJet a policy with s3:* across every bucket in the account. Scope it to the ARN of the bucket you just created, with only the actions ToolJet’s app actually calls.

[Figure 3: Create IAM credentials so ToolJet can talk to this bucket]

Back in ToolJet, go to Data Sources, add a new source, and pick Amazon S3. Choose an authentication method (IAM Access Keys, AWS Instance Credentials, or ARN Role), fill in the region plus your keys, then test and save. If you’re running an S3-compatible store instead of standard AWS S3, MinIO, Wasabi, or a private on-prem deployment, ToolJet lets you point at a custom endpoint rather than the default AWS one. That’s useful for hybrid infrastructure or air-gapped environments where a real AWS endpoint isn’t reachable at all.

[Figure 4: Connect S3 datasource to ToolJet]

[Figure 5: Go to ToolJet’s App Builder]

This build uses four queries against the S3 data source, named getBuckets, getObjects, uploadObject, and getSignedUrl. Start with getBuckets. Its operation is set to List buckets, and it takes no parameters at all. Run it, and it fills a table with every bucket in the account, one column for the bucket name and one for its ARN.

[Figure 6: getObjects query to list objects in the selected bucket]

Click a row in that bucket table, and getObjects fires next. Its operation is List objects in a bucket. You only touch those once a bucket has more files than one page can hold. Run it, and every file in the selected bucket lands in a second table, this one showing Name, last modified, size, and checksum details pulled straight from S3’s response.

uploadObject handles the upload side, wired to a text input and a file picker already sitting on the canvas.

[Figure 7: Modal to upload image to S3 bucket]
In plain terms: Key takes whatever name the user typed into the text input and tacks the original file extension back onto it, so a user typing “march-report” uploading a .pdf ends up with march-report.pdf. Content Type and Upload data both come straight off the file sitting in the file picker, and Encoding tells S3 the upload data arrives as base64 text, not raw bytes.

getSignedUrl runs on the Signed url for download operation, with two fields.

Click a file in the objects table, run the query, and ToolJet hands back one URL good for 3,600 seconds, an hour, before it stops working on its own. No AWS login needed on the other end, and no change to the bucket’s actual permissions.

Want to skip the from-scratch build? Browse ToolJet’s app templates for a file explorer starting point instead of wiring every query by hand.

Put these four queries together, getBuckets, getObjects, uploadObject, getSignedUrl, and you already have the shape of most internal S3 tools: a file explorer, a document approval queue, a backup and audit browser, or a media library your non-technical teammates can use without ever opening the AWS console.

[Figure 8: AWS S3 File Explorer (finished app view)]

Good use cases here run the gamut. Internal file explorers, document approval workflows, backup and audit browsers, and media management tools where non-technical staff need a simple UI instead of the raw AWS console.

DynamoDB is Amazon’s managed NoSQL database, and once ToolJet is connected, it can read from and write to it just like any other data source. Connecting the two takes a handful of steps, and getting the authentication choice right up front saves a support ticket down the line.

Follow these steps to connect ToolJet to DynamoDB:

1. Open Data Sources from the ToolJet dashboard, or click + Add new Data source directly in the query panel of an app.
2. Select DynamoDB from the list of available data sources.
3. Choose an authentication method: IAM Credentials, AWS Instance Credentials, or AWS ARN Role.
4. Enter your Region, plus Access key and Secret key for IAM Credentials, or the Role ARN if you picked that method instead.
5. Click Test Connection to confirm ToolJet can reach your table, then Save.

If step 3 has you second-guessing which method to pick, the short version: use IAM Credentials while you’re still prototyping, since it’s the fastest to set up, and move to AWS Instance Credentials once ToolJet is actually deployed on EC2 or ECS, since that removes long-lived keys from your configuration entirely. The full breakdown of when each method makes sense is covered earlier in what authentication methods ToolJet supports for AWS.

Troubleshooting tip: If the connection succeeds but your query returns no data, verify the table name, AWS region, and partition key values before assuming there’s an authentication issue.

[Figure 9: DynamoDB Data Source – Testing Connection]

Once the connection tests successfully and you hit Save, the data source is live and ready for queries. Add a new query, pick your DynamoDB source, and choose an operation: list tables, get or put an item, query, scan, update, delete, describe a table, or create one. Each runs through parameter fields or raw JSON matching DynamoDB’s native API shape, and results bind straight to a table, chart, or any other component on the canvas.

Building your first internal tool on top of a NoSQL store? Check ToolJet’s data source documentation for the exact field names your DynamoDB region expects.

A common first build on top of DynamoDB is an internal employee directory, the kind of app HR and IT teams reach for so nobody has to open the AWS console just to look up a coworker.

A typical employee directory app on DynamoDB includes:

• One table listing every employee record
• Columns for name, employee ID, and department
• A profile photo pulled in per row
• An “Add DOB” button wired to Update Item
• Search and pagination built into the table

[Figure 10: Employee Directory]

Each employee lives as a single DynamoDB item, keyed by employee ID, with attributes for name, department, date of birth, and a photo URL. Selecting a row highlights it, and adding a field like date of birth is just an Update Item query bound to a button, no schema migration required since DynamoDB items don’t enforce a fixed set of attributes.

Thinking about what your own internal directory should track? See ToolJet’s table component documentation for how row selection and column formatting work before wiring up your own version.

The same pattern carries past HR data. Asset tracking, session logs, and ticket queues all follow the same shape once photos, status badges, or action buttons get added to the columns.

Need to reshape the payload before it hits the UI? Transformations let you run JavaScript or Python against the raw response first.

A handful of practices apply no matter which AWS service ToolJet is talking to, so it’s worth treating this as a checklist rather than a one-time read.

Lock these down before going live:

• Least-privilege IAM policies only
• Instance roles over static keys
• Restricted network and VPC access
• Rotated credentials and certificates
• Private tunnels instead of public endpoints

Start with least privilege. Build a dedicated IAM user or role for ToolJet with only the actions it needs, dynamodb:Query and dynamodb:Scan, not dynamodb:*. In production, prefer instance roles over static keys wherever ToolJet actually runs on EC2 or ECS. That one change alone removes long-lived secrets from your configuration entirely. Network access matters just as much. Whether it’s a security group, a VPC setting, or a bucket policy, restrict inbound access to exactly what ToolJet’s deployment needs and nothing wider.

Certificates expire too, not just keys. Keep your CA bundle current so a connection doesn’t silently start failing the day AWS retires an old root certificate. And for anything that doesn’t strictly need to be public, use SSH tunneling or VPC peering rather than opening a database endpoint to the internet just to make the ToolJet connection easier to set up.

Curious how ToolJet handles this at the platform level? Read ToolJet’s security model before you finalize IAM policies for a production rollout.

Picking where a new internal tool’s data should live gets easier with a simple mental model in front of you.

Most internal tools end up using multiple AWS services together. This comparison can help you decide which service is best suited for each part of your application.

Quick signals worth checking before you decide:

• Read pattern by key or by file
• Expected request volume per second
• Whether files need public sharing
• Existing IAM structure in your account
• Team familiarity with each service

If your app is mostly key-based lookups on structured records, session data, or event logs, DynamoDB is the natural fit. If the app is really about files, uploads, or anything users need to download later, S3 wins every time. Most real internal tools end up touching both.

Not sure your current stack even needs a new service? Compare ToolJet’s approach to internal tool builders before adding another AWS dependency to the mix.

ToolJet’s AWS connectors follow one consistent pattern. Pick an authentication method, IAM keys for speed, instance roles or ARN assumption for production. Configure network access so ToolJet can actually reach the endpoint. Then build queries through the visual query builder or raw JSON, whichever the operation calls for. Once that initial connection exists, the same app can pull from S3 and DynamoDB at once, which is exactly the kind of cross-service internal tool ToolJet was built to make fast. As an enterprise low-code platform with no per-end-user charges and self-hosted deployment options, ToolJet keeps that flexibility without locking your data behind a proprietary layer.

For the most current field-by-field configuration details, cross-reference ToolJet’s official data source documentation, since connector options do shift between releases.

Ready to connect your own AWS account? Try ToolJet and wire up your first S3 or DynamoDB query in a single afternoon.