Signal

SSH into your VPS and install Docker if not already present. Create a directory for your Signal bridge and a persistent data volume directory. The signal-cli-rest-api container needs this volume to persist the Signal session (registration state) across container restarts — without it, you'd have to re-register the phone number every time the container restarts. Pull the image and start the container. The container exposes an HTTP API on port 8080 by default. Set the `MODE` environment variable to `normal` for standard operation. Pass the storage volume mount and set your phone number via environment variable. Here's a minimal Docker run command: ``` docker run -d \ --name signal-api \ -p 8080:8080 \ -v /path/to/signal-data:/home/.local/share/signal-cli \ -e MODE=normal \ bbernhard/signal-cli-rest-api ``` Once running, check that the container is live with `docker logs signal-api`. You should see the HTTP server starting. The container is listening on port 8080, but do NOT expose this port to the public internet yet — it has no authentication by default. In the next steps, you'll register a phone number and then secure the bridge.

1# docker-compose.yml (recommended for easier management)
2version: '3'
3services:
4  signal-api:
5    image: bbernhard/signal-cli-rest-api
6    container_name: signal-api
7    environment:
8      - MODE=normal
9    ports:
10      - "127.0.0.1:8080:8080"  # Bind to localhost only — not public
11    volumes:
12      - ./signal-data:/home/.local/share/signal-cli
13    restart: unless-stopped

With the container running, you need to register a phone number as a Signal account linked to this bridge. This is a one-time operation done directly on the server — not from FlutterFlow. Step 1 — Request a verification code: call the bridge's registration endpoint, specifying your phone number in E.164 format (e.g., +14155552671) and how you want to receive the code (sms or voice): ``` curl -X POST http://localhost:8080/v1/register/{PHONE_NUMBER} -H "Content-Type: application/json" -d '{"use_voice": false}' ``` Signal will send a 6-digit SMS verification code to that phone number. Step 2 — Verify the code: ``` curl -X POST http://localhost:8080/v1/register/{PHONE_NUMBER}/verify/{CODE} ``` Replace {CODE} with the 6-digit code you received. If successful, the bridge returns a 201 response and writes the session to your mounted data volume. The phone number is now registered as a Signal account on this bridge. Test it by sending yourself a Signal message: ``` curl -X POST http://localhost:8080/v2/send \ -H "Content-Type: application/json" \ -d '{"number": "+14155552671", "recipients": ["+1YOUR_PHONE"], "message": "Hello from the bridge!"}' ``` Check Signal on your personal phone — you should receive the message from your bridge's registered number.

1# Registration flow (run on the VPS server via curl or wget)
2# Step 1: Request SMS code
3curl -X POST 'http://localhost:8080/v1/register/+14155552671' \
4  -H 'Content-Type: application/json' \
5  -d '{"use_voice": false}'
6
7# Step 2: Verify the code (replace 123456 with real code)
8curl -X POST 'http://localhost:8080/v1/register/+14155552671/verify/123456'
9
10# Test send
11curl -X POST 'http://localhost:8080/v2/send' \
12  -H 'Content-Type: application/json' \
13  -d '{
14    "number": "+14155552671",
15    "recipients": ["+1RECIPIENT_NUMBER"],
16    "message": "Test from FlutterFlow bridge"
17  }'

The bridge has no authentication by default. Anyone who can reach port 8080 can send Signal messages as your registered number. You must secure it before calling it from FlutterFlow. Option A (recommended): Put the bridge behind a **Cloud Function proxy**. The Cloud Function runs on Google's servers, can reach your VPS bridge via its internal IP or a private network, and adds an auth layer between FlutterFlow and the bridge. Deploy a Firebase Cloud Function named `sendSignalMessage` that accepts `{recipient, message}` from FlutterFlow, validates an API key header, then forwards the request to your VPS bridge URL. Store your VPS bridge URL and any API token as Firebase Functions config — not in FlutterFlow. Option B (if you can't use a Cloud Function): Secure the bridge with **Nginx + HTTP Basic Auth** on the VPS, making it publicly accessible only over HTTPS with a username/password. Then FlutterFlow calls the bridge directly with Basic Auth. This exposes the bridge URL in the app binary — less ideal, but tolerable if you rotate the password regularly and the bridge URL isn't sensitive. For Option A, your Cloud Function makes a POST to `http://YOUR_VPS_IP:8080/v2/send` (internal/private network) and returns the response to FlutterFlow.

1// index.js (Firebase Cloud Function proxy for Signal bridge)
2const functions = require('firebase-functions');
3const axios = require('axios');
4
5const BRIDGE_URL = functions.config().signal.bridge_url;  // e.g., http://10.0.0.5:8080
6const SENDER_NUMBER = functions.config().signal.sender_number;  // e.g., +14155552671
7const API_SECRET = functions.config().signal.api_secret;  // your own secret token
8
9exports.sendSignalMessage = functions.https.onRequest(async (req, res) => {
10  res.set('Access-Control-Allow-Origin', '*');
11  if (req.method === 'OPTIONS') {
12    res.set('Access-Control-Allow-Methods', 'POST');
13    res.set('Access-Control-Allow-Headers', 'Content-Type, x-api-key');
14    return res.status(204).send('');
15  }
16
17  // Simple auth: check a custom header against your secret
18  if (req.headers['x-api-key'] !== API_SECRET) {
19    return res.status(401).json({ error: 'Unauthorized' });
20  }
21
22  const { recipient, message } = req.body;
23  if (!recipient || !message) {
24    return res.status(400).json({ error: 'recipient and message required' });
25  }
26
27  try {
28    const response = await axios.post(`${BRIDGE_URL}/v2/send`, {
29      number: SENDER_NUMBER,
30      recipients: [recipient],
31      message: message
32    }, {
33      headers: { 'Content-Type': 'application/json' },
34      timeout: 15000
35    });
36    return res.status(200).json({ timestamp: response.data.timestamp });
37  } catch (err) {
38    const status = err.response?.status || 500;
39    return res.status(status).json({ error: err.message });
40  }
41});

In FlutterFlow, click **API Calls** in the left nav → **+ Add** → **Create API Group**. Name it 'Signal Bridge'. Set the Base URL to your Cloud Function URL (e.g., `https://us-central1-your-project.cloudfunctions.net`). Add a shared header: Key = `x-api-key`, Value = `{{apiKey}}`. Add a group-level variable `apiKey` (String). In the Variables tab, you can set the default value of `apiKey` to your API secret — or better, store it in FlutterFlow's **App State** and pass it when initializing the API group. The API key is a shared secret, not a per-user credential, so storing it in App State with a hardcoded initial value is acceptable for this use case (the secret is in the Cloud Function env config; what's in the app is just a key to access your Cloud Function, not direct Signal access). Add an API Call inside the group: name it 'Send Signal Message'. Method = POST, path = `/sendSignalMessage`. Body type = JSON, body fields: `recipient` (variable, E.164 phone number like +14155552671) and `message` (variable, message text). On your send screen, add a TextField for the recipient's phone number, a multiline TextField for the message, and a Send button. Wire the button's Action Flow to: (1) API Request → 'Signal Bridge / Send Signal Message', passing the TextFields as `recipient` and `message`; (2) show a SnackBar 'Message sent via Signal' on 200; (3) show 'Failed to send' on error; (4) clear the form. If this kind of privacy-first integration is important for your use case and you'd rather not manage the VPS yourself, RapidDev's team can help you architect and deploy this infrastructure — free scoping call at rapidevelopers.com/contact.

1{
2  "group": "Signal Bridge",
3  "baseUrl": "https://us-central1-YOUR-PROJECT.cloudfunctions.net",
4  "headers": {
5    "x-api-key": "{{apiKey}}"
6  },
7  "calls": [
8    {
9      "name": "Send Signal Message",
10      "method": "POST",
11      "path": "/sendSignalMessage",
12      "bodyType": "JSON",
13      "body": {
14        "recipient": "{{recipient}}",
15        "message": "{{message}}"
16      },
17      "variables": [
18        { "name": "apiKey", "type": "String" },
19        { "name": "recipient", "type": "String" },
20        { "name": "message", "type": "String" }
21      ]
22    }
23  ]
24}

Receiving inbound Signal replies in FlutterFlow requires polling the bridge's `/v1/receive/{PHONE_NUMBER}` endpoint — Signal doesn't push inbound messages to a webhook in the bridge by default (though the bridge has a `native` mode with WebSocket support for production workloads). For basic inbound polling, add a second API Call in your FlutterFlow Signal Bridge group: name it 'Receive Messages', method = GET, path = `/v1/receive/{PHONE_NUMBER}` (substitute your registered number). Route this through your Cloud Function proxy (add a `/receiveSignalMessages` endpoint to the same function that calls the bridge). Set up a Timer action in FlutterFlow using a Custom Action that triggers every 30 seconds to poll for new messages. For production workloads with real-time inbound messages, switch the Docker container to `native` mode (`MODE=native`) and configure your Cloud Function to listen on the bridge's WebSocket feed. Write inbound messages to Firestore and bind a Firestore real-time stream in FlutterFlow — this is the same pattern used in the Sunshine Conversations integration. **Keeping the bridge running** is critical. signal-cli stores session state in the mounted volume. The container must stay running 24/7 — use `restart: unless-stopped` in docker-compose (included in Step 1's config). Monitor the container with a simple uptime check (UptimeRobot, Betterstack) that hits the `/v1/about` endpoint every 5 minutes. If the number gets banned or rate-limited by Signal, the bridge will start returning errors — monitor your VPS logs. Note: if Signal updates their protocol (which happens without notice to third-party tools), the bridge may stop working until the signal-cli maintainers release an update. Subscribe to the signal-cli GitHub repository for release notifications.

1// Add to index.js — receive endpoint proxy
2exports.receiveSignalMessages = functions.https.onRequest(async (req, res) => {
3  res.set('Access-Control-Allow-Origin', '*');
4  if (req.method === 'OPTIONS') {
5    res.set('Access-Control-Allow-Methods', 'GET');
6    res.set('Access-Control-Allow-Headers', 'Content-Type, x-api-key');
7    return res.status(204).send('');
8  }
9
10  if (req.headers['x-api-key'] !== API_SECRET) {
11    return res.status(401).json({ error: 'Unauthorized' });
12  }
13
14  try {
15    const response = await axios.get(
16      `${BRIDGE_URL}/v1/receive/${SENDER_NUMBER}`,
17      { timeout: 10000 }
18    );
19    return res.status(200).json(response.data);
20  } catch (err) {
21    return res.status(err.response?.status || 500).json({ error: err.message });
22  }
23});