Connection Setup for Salesforce Environments: CLI, VS Code, and CI/CD

Before you can deploy metadata, run Apex, or automate any part of your Salesforce workflow, you need authenticated connections to your orgs. Getting this right from day one — with the correct authentication method for each use case — saves considerable debugging time later.

Session 81 covers three connection contexts: local development via Salesforce CLI, VS Code editor integration, and non-interactive CI/CD pipelines via JWT authentication.

Salesforce CLI org authentication

The Salesforce CLI (sf) stores org connections as authenticated sessions with an alias you define. Each connection maps your local environment to a specific Salesforce org — sandbox, Developer Edition, or production.

For sandboxes, the authentication command is:

sf org login web \
  --instance-url https://test.salesforce.com \
  --alias dev1

The --instance-url https://test.salesforce.com flag directs authentication to the sandbox login endpoint. Without it, the CLI defaults to login.salesforce.com — the production endpoint. The --alias flag sets the shortname you'll use in subsequent commands.

After running this command, a browser window opens for OAuth login. Complete the login in the browser. The CLI captures the OAuth token and stores it locally. You can now run CLI commands against this org using --target-org dev1.

For production:

sf org login web --alias prod

To see all authenticated orgs:

sf org list

To set a default org for your project (so you don't need to specify --target-org on every command):

sf config set target-org dev1 --project

The --project flag writes the setting to your project's .sf/config.json file rather than globally. This means different projects can have different default orgs without interfering with each other.

Token storage and expiry

CLI tokens are stored at ~/.sf/credentials.json. Interactive OAuth sessions expire after 2 hours by default — when the token expires, the next CLI command that requires org access will prompt you to re-authenticate. You can avoid this interruption during long working sessions by refreshing the token: sf org open --target-org dev1 opens the org in a browser and refreshes the session token.

VS Code Salesforce extension setup

Install the Salesforce Extension Pack from the VS Code Marketplace. Once installed, it reads the CLI's authenticated org list — no separate authentication step is needed if you've already authenticated via CLI. The extension adds:

• Apex IntelliSense and syntax highlighting with error detection
• Org Browser in the sidebar for browsing and retrieving metadata without command-line commands
• SOQL Builder for visual query construction with result previews
• LWC support including component preview
• Apex Replay Debugger — replay Apex execution from debug logs as if stepping through a live debugger

The most important VS Code setup step is ensuring your project has a sfdx-project.json file in the root directory. Without it, the Salesforce extension doesn't recognise the project as a Salesforce project and most features remain inactive. A minimal sfdx-project.json:

{
  "packageDirectories": [{ "path": "force-app", "default": true }],
  "sourceApiVersion": "61.0"
}

Connected App setup for CI/CD

Interactive OAuth authentication doesn't work in CI/CD pipelines — there's no browser. The solution is JWT Bearer Token authentication using a Connected App and an RSA key pair.

Step 1: Generate an RSA key pair.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr \
  -signkey server.key -out server.crt

Step 2: Create the Connected App in Salesforce.

Go to Setup → App Manager → New Connected App. Enable OAuth settings. Check "Use digital signatures" and upload your server.crt certificate. Select the required OAuth scopes: at minimum, "Manage user data via APIs (api)" and "Perform requests at any time (refresh_token, offline_access)". Save the app and note the Consumer Key.

Step 3: Authorize the Connected App user.

In Profiles or Permission Sets, the user that the pipeline will authenticate as must be assigned to the Connected App. Go to the Connected App settings → Manage → Manage Profiles (or Permission Sets) and add the appropriate profile.

Step 4: Store the private key in CI/CD secrets.

Store the contents of server.key as an encrypted CI/CD secret — in GitHub Actions as a repository secret, in Bitbucket as an environment variable. Never commit server.key to your repository.

Step 5: Authenticate in the pipeline.

sf org login jwt \
  --client-id ${{ secrets.SF_CONSUMER_KEY }} \
  --jwt-key-file server.key \
  --username ${{ secrets.SF_USERNAME }} \
  --instance-url https://login.salesforce.com \
  --alias prod

Write the key file to disk from the secret before this command, then delete it after authentication. The JWT authentication flow does not require browser interaction — the CLI exchanges the JWT for an access token directly with Salesforce's token endpoint.

Managing multiple environments

A typical Salesforce DevOps setup connects to four orgs: a personal Developer sandbox (dev1), a QA Partial Copy sandbox (qa1), a UAT Full Copy sandbox (uat1), and production (prod). Authenticate to each with the appropriate alias and instance URL. Keep the alias naming consistent across the team so scripts and pipeline YAML files work without per-developer customisation.

For production-level orgs where you want an extra safety layer, the CLI supports a --no-prompt flag combined with confirmation settings that require explicit approval for destructive deployments. This prevents accidental production deploys that would otherwise succeed silently.