How to Integrate Lovable with Signal

Signal integration requires self-hosting the signal-cli-rest-api Docker container on a server you control. This is not a browser-only workflow — you need a Linux VPS or VM with Docker installed. The server must have a publicly accessible IP address or domain name so your Supabase Edge Function can reach it. On your server, create a directory for Signal data and start the container. The official signal-cli-rest-api image is available at Docker Hub as bbernhard/signal-cli-rest-api. A basic Docker Compose configuration starts the container on port 8080 and mounts a persistent volume for Signal account data. Set the MODE environment variable to 'json-rpc' for the REST API mode. After the container starts, register your dedicated phone number with Signal. Send a POST request to http://localhost:8080/v1/register/{phone_number} where phone_number is in E.164 format (e.g., +12025551234). This triggers a verification SMS or voice call to the number. Complete verification by POST to /v1/register/{phone_number}/verify/{verification_code} with the received code. For production use, secure the relay with basic authentication or an API key by setting environment variables in the Docker Compose file. Never expose the relay directly to the public internet without authentication — anyone who can reach port 8080 can send Signal messages as your registered number. Use a firewall to restrict access to port 8080 to only Supabase's IP ranges or use authentication middleware.

1# docker-compose.yml for signal-cli-rest-api
2version: '3'
3services:
4  signal-cli-rest-api:
5    image: bbernhard/signal-cli-rest-api:latest
6    environment:
7      - MODE=json-rpc
8      - PORT=8080
9    ports:
10      - "127.0.0.1:8080:8080"  # bind to localhost only, use nginx reverse proxy for HTTPS
11    volumes:
12      - ./signal-data:/home/.local/share/signal-cli
13    restart: unless-stopped

Your Supabase Edge Function needs to reach the relay over HTTPS with authentication. Set up an Nginx reverse proxy in front of the signal-cli-rest-api container. Install Certbot for a free Let's Encrypt SSL certificate on your domain. Configure Nginx to require HTTP Basic Auth (create credentials with htpasswd) and proxy requests to the local Docker container on port 8080. Once the relay is secured with HTTPS and Basic Auth, you have three pieces of information for Lovable Secrets: the relay base URL (https://signal.yourdomain.com), the Basic Auth username, and the Basic Auth password. In Lovable's Cloud tab → Secrets, add: SIGNAL_RELAY_URL with your full relay URL (e.g., https://signal.yourdomain.com), SIGNAL_RELAY_USERNAME with the Basic Auth username, SIGNAL_RELAY_PASSWORD with the Basic Auth password, and SIGNAL_PHONE_NUMBER with the E.164 format number registered with Signal on the relay. Lovable's infrastructure encrypts all four secrets at rest. The relay credentials grant full access to send Signal messages from your registered number — treat them with maximum care. Never paste them in Lovable chat prompts. The platform's SOC 2 Type II certification and active credential-blocking security (approximately 1,200 blocked per day) ensure credentials stay safe when stored in the Secrets panel.

1# /etc/nginx/sites-available/signal-relay
2server {
3    listen 443 ssl;
4    server_name signal.yourdomain.com;
5
6    ssl_certificate /etc/letsencrypt/live/signal.yourdomain.com/fullchain.pem;
7    ssl_certificate_key /etc/letsencrypt/live/signal.yourdomain.com/privkey.pem;
8
9    location / {
10        auth_basic "Signal Relay";
11        auth_basic_user_file /etc/nginx/.htpasswd;
12
13        proxy_pass http://127.0.0.1:8080;
14        proxy_set_header Host $host;
15        proxy_set_header X-Real-IP $remote_addr;
16    }
17}

Create an Edge Function called signal-message that proxies message requests to your self-hosted relay. The function reads the relay URL and credentials from Secrets, constructs the Basic Auth header, and POSTs to the signal-cli-rest-api send endpoint. The signal-cli-rest-api v2 send endpoint is POST /v2/send with a JSON body containing message (string), number (the sender — your registered number), and recipients (array of E.164 numbers or group IDs). For individual messages, recipients is a single-element array. The function should validate that the 'to' number is in E.164 format before sending. Add basic sanitization to prevent misuse — consider implementing rate limiting by checking a Supabase table for send counts per user per hour. Signal does not have explicit rate limits published, but sending too many messages too quickly can trigger Signal's abuse detection and potentially result in the number being flagged. Ask Lovable to generate the Edge Function. After deployment, test it by sending a message to your own Signal number to verify the relay is reachable and credentials are correct.

1// supabase/functions/signal-message/index.ts
2import { serve } from 'https://deno.land/std@0.168.0/http/server.ts';
3
4const corsHeaders = {
5  'Access-Control-Allow-Origin': '*',
6  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
7};
8
9serve(async (req) => {
10  if (req.method === 'OPTIONS') return new Response('ok', { headers: corsHeaders });
11
12  try {
13    const relayUrl = Deno.env.get('SIGNAL_RELAY_URL')!;
14    const username = Deno.env.get('SIGNAL_RELAY_USERNAME')!;
15    const password = Deno.env.get('SIGNAL_RELAY_PASSWORD')!;
16    const fromNumber = Deno.env.get('SIGNAL_PHONE_NUMBER')!;
17
18    const { to, message } = await req.json();
19
20    if (!to || !to.startsWith('+')) {
21      throw new Error('Recipient must be in E.164 format (e.g., +12025551234)');
22    }
23    if (!message || message.trim().length === 0) {
24      throw new Error('Message cannot be empty');
25    }
26
27    const credentials = btoa(`${username}:${password}`);
28
29    const res = await fetch(`${relayUrl}/v2/send`, {
30      method: 'POST',
31      headers: {
32        'Authorization': `Basic ${credentials}`,
33        'Content-Type': 'application/json',
34      },
35      body: JSON.stringify({
36        message: message.substring(0, 1000), // Signal message length limit
37        number: fromNumber,
38        recipients: [to],
39      }),
40    });
41
42    const responseText = await res.text();
43    if (!res.ok) throw new Error(`Relay error ${res.status}: ${responseText}`);
44
45    return new Response(
46      JSON.stringify({ success: true, status: 'sent' }),
47      { headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
48    );
49  } catch (error) {
50    return new Response(
51      JSON.stringify({ error: error.message }),
52      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
53    );
54  }
55});

signal-cli-rest-api supports receiving inbound messages by either polling the /v1/receive/{number} endpoint or configuring a webhook callback URL. The webhook approach is more suitable for Lovable — configure the relay to POST incoming messages to your Edge Function URL. In the relay configuration (via environment variables or the signal-cli-rest-api config file), set the RECEIVE_MODE to 'on-start' and configure a webhook URL pointing to your deployed Edge Function. Alternatively, create a scheduled Edge Function that polls /v1/receive/{number} every minute and stores new messages in Supabase. The polling approach is simpler but introduces up to a 1-minute delay for inbound messages. The webhook approach requires your relay to be able to make outbound HTTP requests to Supabase's Edge Function URLs. For real-time two-way messaging, the webhook pattern is recommended. Create a second Edge Function called signal-inbound that receives POST callbacks from the relay, parses the message data (sender number, message text, timestamp), and inserts rows into a signal_messages table in Supabase. Use Supabase Realtime on this table to push inbound messages to your Lovable frontend in real time. For complex two-way messaging with conversation threading and agent management, RapidDev's team can help design the full inbox architecture.