Fix Slow or Stuck AWS Profile Loading in Dynobase

Slow profile loading in Dynobase can come from credentials that need authentication, unreadable AWS configuration, failed network requests or loading more profiles and Regions than you need. Dynobase 3 loads Regions lazily by default, so a missing table can also mean its Region has not loaded yet. Start with the displayed diagnostic and verify the same profile and Region through AWS CLI v2.

1. Update Dynobase and identify what is waiting

Install the current build for your operating system from Download. Dynobase 3 includes profile, SSO and region-loading changes that older screenshots and troubleshooting instructions do not describe.

Distinguish the state you see before changing configuration:

A profile name appearing in the app does not prove it has active credentials. Similarly, a cached table name does not prove a fresh request to that table has succeeded.

2. Verify the profile and Region outside the app

Replace work and us-east-1 with the profile and DynamoDB Region you use in Dynobase:

aws sts get-caller-identity --profile work --region us-east-1
aws dynamodb list-tables --profile work --region us-east-1
aws sts get-caller-identity --profile work --region us-east-1
aws dynamodb list-tables --profile work --region us-east-1

get-caller-identity confirms the account and role without printing secret credentials. list-tables tests DynamoDB access in that Region. An empty table list can be a valid response for the wrong account or Region; it is not necessarily a connection failure.

If identity succeeds but listing tables returns AccessDenied, review the role's DynamoDB permissions. If either request times out, investigate DNS, VPN, firewall or proxy access to the relevant AWS service. These commands test different services, so success from STS alone does not establish that DynamoDB is reachable.

If both commands work, compare the AWS files and environment used by the app with those used by your terminal. A desktop application does not necessarily inherit variables exported in a shell.

3. Check AWS configuration files and profile inclusion

Dynobase reads AWS config and credentials files, normally ~/.aws/config and ~/.aws/credentials. Named config sections use [profile work]; credentials-file sections use [work]. SSO and credential-process profiles can be configured without static keys in a credentials file.

In Settings > General, check AWS config and credentials files. Explicit app paths take precedence; otherwise the app can use AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE from its environment, followed by the default paths. Use Apply paths after changing an override, or Reset to defaults to clear it.

If startup has not reached the main workspace, use the file-selection or retry action offered by the setup diagnostic. A malformed or unreadable file should be repaired rather than repeatedly reloaded. Do not remove working profiles merely to clear a loading message.

Under Included AWS Profiles, select the profiles you need and use Reload profiles. You can also exclude a profile from the visible list by adding this setting to its config section:

[profile profile-not-for-dynobase]
region = us-east-1
dynobase_skip = true
[profile profile-not-for-dynobase]
region = us-east-1
dynobase_skip = true

Remove the setting when you want that profile available again. A source profile referenced by an included role may still be needed to resolve credentials, even when it is excluded from the visible list. Profile exclusion is a loading preference, not a security boundary.

4. Resolve SSO, MFA and credential-process prompts

For an IAM Identity Center profile, run:

aws sso login --profile work
aws sso login --profile work

Then retry in Dynobase, or choose Authenticate in the app and complete the browser sign-in. Standard sso_session configuration is supported directly; the SSO guide shows the setup. Repeating login will not fix missing permissions or a reference to a nonexistent session block.

For MFA, complete the prompt associated with the affected profile. For credential_process, confirm that the configured executable exists and works with its source profile. The process must return valid credential JSON; a terminal-only prompt may wait without a usable input terminal when started from the app.

The aws-vault guide covers full executable paths, prompt behavior and refresh. Do not share credential-process JSON output with support: it contains credentials.

5. Keep lazy region loading enabled

In Settings > General > Region loading, Load regions lazily is on by default. Cached table lists can appear immediately while the default and previously opened Regions refresh. Other Regions load when expanded; Load all regions requests the remaining Regions when you need a broader table search.

Turning lazy loading off makes startup scan every Region of each included profile before showing tables and can make startup slower. A change applies on the next profile reload.

Use Excluded Regions to skip Regions you do not use. Before diagnosing a missing table, verify that its Region is not excluded and has actually loaded. An all-profiles search over the currently loaded table lists is not proof that a table does not exist in an unloaded Region.

6. Check proxy and certificate settings

A corporate network may require a proxy or a custom certificate authority. Dynobase has Proxy Settings in General settings and supports custom certificate bundles. Check these against your organization's network requirements and the error being shown.

Restart the app after changing the proxy setting. Reload profiles after changing the custom certificate bundle. Prefer supplying the required trust chain over disabling certificate validation. If the terminal works while the app fails, compare their proxy and certificate settings as well as their AWS file paths. Related options are covered in workspace settings.

7. Separate local DynamoDB problems from AWS profiles

In Offline Settings, check DynamoDB-compatible Endpoints and use Test connection for an explicit local endpoint. Point it at the service actually running, such as http://localhost:8000 for a typical DynamoDB Local setup or http://localhost:4566 for LocalStack.

The Legacy DynamoDB Local Port setting is retained for compatibility. Changing it is not a general fix for slow AWS authentication: automatic discovery also checks known local endpoints, including port 8000. If another application occupies a local port, configure the correct DynamoDB endpoint and test that connection instead of choosing an arbitrary unused port.

For local tables that are missing despite a successful connection, compare the endpoint, Region and access-key configuration used when creating them. The DynamoDB Local guide explains local database-file separation and shared-database mode.

If loading still fails

Use Copy diagnostics when the setup panel offers it. Record the Dynobase version, operating system, error text, profile type, affected Region and whether each CLI check succeeded. Review diagnostic details before sharing them; do not include access keys, secrets, session tokens, MFA codes or raw credential-process output.

That information distinguishes a file-discovery problem from authentication, authorization, networking or an unloaded Region. It also avoids changing several unrelated settings at once and losing the evidence for the original failure.