TensorFlow

Before configuring Bubble, make sure your TensorFlow Serving instance is running and accessible. This step clarifies the REST API structure you will be calling from Bubble. **TensorFlow Serving REST API format:** POST `/v1/models/{model_name}:predict` The `model_name` matches the directory name you mounted when starting TensorFlow Serving. For example, if you started Serving with `--model_name=price_predictor`, the endpoint is: `http://your-server:8501/v1/models/price_predictor:predict` The request body always wraps inputs in an `instances` array: ```json { "instances": [ { "feature_1": value1, "feature_2": value2 } ] } ``` The response always wraps outputs in a `predictions` array: ```json { "predictions": [ [...] ] } ``` For tabular models, each item in `predictions` is typically an array of probabilities (one per class) or a single float (for regression). For classification, `predictions[0]` is often an array — `predictions[0][class_index]` gives the probability for a specific class. To inspect your model's expected input field names, run: `saved_model_cli show --dir /path/to/saved_model --all` This outputs the SignatureDef with exact tensor names (e.g., `serving_default_input_1`, `dense_input`) — these are the field names you must use inside the instances object. Wrong names return 400 errors without clear error messages. **Version handling:** If your serving instance has multiple model versions, the endpoint includes the version: `/v1/models/{model_name}/versions/{version}:predict` Omitting the version serves the latest version automatically.

1// TensorFlow Serving REST API:
2// Base: http://your-host:8501
3// Predict endpoint: POST /v1/models/{model_name}:predict
4//
5// Request body:
6{
7  "instances": [
8    {
9      "your_input_tensor_name": value
10    }
11  ]
12}
13
14// Response body:
15{
16  "predictions": [
17    [0.1, 0.7, 0.2]  // array of class probabilities for classification
18  ]
19}
20
21// For regression models:
22{
23  "predictions": [
24    [42.5]  // array containing single predicted value
25  ]
26}
27
28// Inspect model inputs:
29// saved_model_cli show --dir /path/to/savedmodel --all
30// Look for: signature_def['serving_default'].inputs
31// Note the exact tensor name strings — use these in instances
32
33// Health check endpoint:
34// GET /v1/models/{model_name}
35// Returns model status and version info

Bubble's API Connector requires HTTPS for all external API calls. TensorFlow Serving runs on plain HTTP at port 8501 by default — you must add TLS termination before Bubble can connect to it. **Option A: nginx reverse proxy with Let's Encrypt (recommended for cloud VMs)** Install nginx on your server: ``` sudo apt install nginx certbot python3-certbot-nginx ``` Create an nginx server block that proxies HTTPS traffic to TensorFlow Serving's local HTTP port 8501. After configuring nginx, run Certbot to obtain a free Let's Encrypt certificate: ``` sudo certbot --nginx -d your-domain.com ``` Certbot automatically updates the nginx config to enable HTTPS with the Let's Encrypt certificate. **Option B: Cloud load balancer (GCP, AWS, DigitalOcean)** Create a cloud load balancer with an SSL certificate pointing to your TensorFlow Serving VM on port 8501. The load balancer handles TLS termination — Bubble sends HTTPS to the load balancer, which forwards plain HTTP to port 8501 internally. This is the managed alternative that requires no nginx configuration. **Option C: Run on GCP AI Platform or similar (managed)** If you deployed your model via Google Cloud AI Platform (Vertex AI), it already serves via HTTPS with Google-managed TLS. See the Vertex AI guide for the authentication steps required in that case. **Adding a simple API key check in nginx (optional but recommended):** Add a `valid_referers` or `if ($http_x_api_key != 'your_secret')` check in your nginx location block to reject unauthenticated requests. Store this key as a Private header in Bubble's API Connector. This is simpler than setting up proper service account auth and sufficient for protecting a self-hosted model endpoint.

1# nginx reverse proxy configuration for TensorFlow Serving
2# File: /etc/nginx/sites-available/tensorflow-serving
3
4server {
5    listen 443 ssl;
6    server_name your-domain.com;
7
8    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
9    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;
10
11    location /v1/models/ {
12        # Optional: simple API key check
13        if ($http_x_api_key != 'your-random-secret-key') {
14            return 401;
15        }
16
17        proxy_pass http://127.0.0.1:8501;
18        proxy_set_header Host $host;
19        proxy_set_header X-Real-IP $remote_addr;
20        proxy_read_timeout 60s;
21    }
22}
23
24server {
25    listen 80;
26    server_name your-domain.com;
27    return 301 https://$server_name$request_uri;
28}
29
30# Start TensorFlow Serving (Docker example):
31# docker run -p 8501:8501 \
32#   --mount type=bind,source=/path/to/savedmodel,target=/models/price_predictor \
33#   -e MODEL_NAME=price_predictor \
34#   tensorflow/serving

In your Bubble editor, click Plugins in the left sidebar and locate the API Connector plugin. Click 'Add another API' and name it 'TensorFlow Serving.' Set the base URL to your TensorFlow Serving HTTPS endpoint, stopping before the model path: `https://your-domain.com` If you added an API key check in nginx, add a shared header at the API group level: - Name: `X-Api-Key` - Value: `your-random-secret-key` - Check the **Private** checkbox Add another shared header: - Name: `Content-Type` - Value: `application/json` Click 'Add another call' and name it 'Predict.' Set: - Method: POST - URL: `/v1/models/price_predictor:predict` (replace `price_predictor` with your model name) - Use as: Action For the JSON body, create the instances array. The structure depends on your model's input schema. For a tabular model with features `feature_1`, `feature_2`, and `feature_3`: ```json { "instances": [ { "feature_1": "<dynamic_feature_1>", "feature_2": "<dynamic_feature_2>", "feature_3": "<dynamic_feature_3>" } ] } ``` Mark each feature as a dynamic parameter with the appropriate type (text, number, or list depending on your model's input). Click 'Initialize call.' Provide real test values that match your model's expected input types (numbers in the correct range, strings in the correct format). A successful initialization returns the `predictions` array — Bubble detects the response structure for binding.

1// API Connector: TensorFlow Serving → Predict
2// Method: POST
3// Base URL: https://your-domain.com
4// Call URL: /v1/models/your_model_name:predict
5//
6// Shared headers:
7// X-Api-Key: your-secret  // mark Private (if nginx auth enabled)
8// Content-Type: application/json
9//
10// JSON body (tabular model example):
11{
12  "instances": [
13    {
14      "usage_frequency": "<dynamic_usage_frequency>",
15      "days_since_login": "<dynamic_days_since_login>",
16      "support_tickets": "<dynamic_support_tickets>",
17      "subscription_age": "<dynamic_subscription_age>"
18    }
19  ]
20}
21
22// Note: Field names must EXACTLY match the model's SignatureDef input names
23// Use saved_model_cli to inspect: saved_model_cli show --dir /model --all
24
25// Response:
26{
27  "predictions": [
28    [0.23, 0.77]  // Example: [probability_no_churn, probability_churn]
29  ]
30}

With the API Connector configured, build the Bubble workflow that collects user inputs and fires the prediction call. On a Bubble page, create a form with input fields matching your model's expected inputs. For a churn prediction model: - Number Input: 'Days since last login' - Number Input: 'Weekly usage count' - Number Input: 'Support tickets (last 30 days)' - Number Input: 'Subscription age (months)' - Button: 'Predict churn risk' - Text element: 'Prediction result' (initially hidden) In the workflow editor, create a workflow triggered by 'Button is clicked.' **Action 1:** Show a loading indicator. **Action 2:** Call 'Plugins → TensorFlow Serving → Predict.' Map the body parameters to the form inputs: - `usage_frequency` = Weekly usage input's value - `days_since_login` = Days input's value - `support_tickets` = Tickets input's value - `subscription_age` = Subscription age input's value **Action 3:** Set a Custom State to the result. The prediction value path is `predictions[0]` (first item in the predictions array). For multi-class classification, this is itself an array of probabilities — use `predictions[0][1]` to get the probability for the positive class (e.g., churn=yes). **Action 4:** Display the result. Show the result Text element and set its content to the Custom State. For binary classification, map the probability to a human-readable label: - If Custom State > 0.7: show 'High risk' in red - If Custom State > 0.4: show 'Medium risk' in yellow - Otherwise: show 'Low risk' in green Use Bubble's Conditional feature on the Text element's color and content based on the Custom State value. For security and reliability, run the API call in a Backend Workflow rather than client-side — this ensures the API key header is never visible in browser DevTools even if something goes wrong with the Private checkbox during Bubble updates.

1// Bubble workflow: Predict button clicked
2//
3// Action 1: Show 'Loading' element
4//
5// Action 2: Plugins → TensorFlow Serving → Predict
6//   usage_frequency: Usage Input's value
7//   days_since_login: Days Input's value
8//   support_tickets: Tickets Input's value
9//   subscription_age: Age Input's value
10//
11// Action 3: Set Custom State 'churn_probability'
12//   Value: Result of step 2's predictions[0][1]
13//   (index 1 = probability of churn=yes for binary classifier)
14//
15// Action 4: Hide 'Loading' element
16// Action 5: Show 'Result' element
17
18// Bubble conditional for risk badge color:
19// Text element 'Risk Level':
20//   Default text: 'Low Risk' (green)
21//   When churn_probability state > 0.4: 'Medium Risk' (yellow)
22//   When churn_probability state > 0.7: 'High Risk' (red)
23
24// Parsing predictions for different model types:
25//
26// Binary classification (2 classes):
27// predictions[0] = [0.23, 0.77]  → predictions[0][1] = churn probability
28//
29// Multi-class (N classes):
30// predictions[0] = [0.1, 0.7, 0.2]  → argmax = class 1 (highest probability)
31//
32// Regression (single output):
33// predictions[0] = [42.5]  → predictions[0][0] = predicted value

If your TensorFlow model takes images as input (computer vision models for classification, object detection, or segmentation), the integration requires one additional step: converting the user's uploaded image to a base64 string before sending it to TensorFlow Serving. TensorFlow image models typically expect one of these formats in the instances array: - Base64-encoded image bytes: `{ "b64": "<base64_string>" }` - A flat pixel array (uncommon for Bubble integrations due to size) In Bubble, users upload images via the File Uploader element. This generates a URL pointing to Bubble's file storage. To convert this URL to base64, you need a Backend Workflow that fetches the file and encodes it — or you can pass the image URL directly to a separate endpoint that handles the conversion. **Practical approach for Bubble:** Use a simple Cloudflare Worker or lightweight Cloud Function that: 1. Accepts an image URL as a parameter 2. Downloads the image 3. Converts it to base64 4. Returns the base64 string Alternatively, if your TensorFlow model accepts URLs directly (some custom models do), pass the Bubble file URL as a feature string — this requires modifying the TensorFlow Serving model's preprocessing layer. **For base64 models, the instances body looks like:** ```json { "instances": [ { "b64": "<base64_encoded_image_string>" } ] } ``` The base64 string can be quite large (hundreds of KB for typical photos) — this consumes significant Bubble Workload Units and may hit API Connector body size limits. For image models, consider serving the TensorFlow endpoint via Google Cloud AI Platform (Vertex AI) which handles large payloads more gracefully and provides managed scaling.

1// TensorFlow Serving body format for image models:
2{
3  "instances": [
4    {
5      "b64": "<base64_encoded_image_string>"
6    }
7  ]
8}
9
10// Note: The "b64" key is TensorFlow Serving's standard way to pass
11// binary data encoded as base64 in a JSON body.
12
13// Bubble workflow for image prediction:
14// 1. User uploads file via File Uploader
15// 2. Backend Workflow: call base64 conversion endpoint
16//    (a Cloud Function or Cloudflare Worker that fetches and encodes the file)
17// 3. Store base64 string in Custom State
18// 4. Call TensorFlow Serving Predict with {"b64": Custom State value}
19// 5. Parse predictions array and display result
20
21// Image input limitations:
22// - base64 of a 500KB JPEG ≈ 667KB string
23// - Large API Connector bodies consume more Bubble WU
24// - Bubble API Connector may have body size limits — test with your image sizes
25// - For large images, resize client-side before upload (use Bubble's Image optimizer)
26// - Consider Vertex AI (managed) over self-hosted TF Serving for image models

Before going live, validate the complete pipeline and set up monitoring for your self-hosted TensorFlow Serving endpoint: **1. Initialize call validation:** Re-run the Initialize call in Bubble's API Connector with your current HTTPS endpoint. Confirm it returns the `predictions` array. If you updated your model (retrained with new features or classes), the response shape may have changed — re-initialize to update Bubble's detected response fields. **2. Model version testing:** If you have multiple model versions (v1, v2, etc.), test both via their version-specific endpoints before switching Bubble to the new URL. TensorFlow Serving serves the highest version number by default — to pin to a specific version, use `/v1/models/{name}/versions/{version}:predict`. **3. Input schema drift:** If your model is retrained with new feature columns or renamed tensors, the old Bubble API call body will silently send wrong field names. TensorFlow Serving may return predictions based on defaults or zeros rather than returning an explicit error. Always validate predictions with known-good inputs after a model update. **4. HTTPS certificate renewal:** Let's Encrypt certificates expire every 90 days. Certbot sets up automatic renewal, but verify renewal is configured: `sudo certbot renew --dry-run`. If the certificate expires, Bubble's API Connector will return a TLS error and all prediction calls will fail silently. **5. WU cost awareness:** Each TensorFlow Serving prediction call from Bubble consumes Workload Units. For high-traffic apps where many users request predictions frequently, cache prediction results in Bubble's database: store inputs + outputs in a Predictions data type, and check for an existing prediction before calling TF Serving. This reduces API calls for duplicate or similar inputs. **6. Privacy rules:** Add Bubble Privacy rules to any Prediction data type you create — ensure each user can only read their own prediction records. RapidDev's team has shipped custom ML model integrations in Bubble apps across multiple industries — for complex model serving architecture or scaling guidance, reach out at rapidevelopers.com/contact.

1// Model version endpoints:
2// Latest version (auto):
3// POST /v1/models/{model_name}:predict
4//
5// Specific version:
6// POST /v1/models/{model_name}/versions/2:predict
7//
8// Model status check:
9// GET /v1/models/{model_name}
10// Response: {"model_version_status": [{"version": "2", "state": "AVAILABLE"}]}
11
12// Prediction caching in Bubble:
13// Data type: Prediction_Cache
14// - input_hash (text)  — e.g., MD5 or concatenated input values
15// - output (text)      — stored prediction result
16// - model_version (text)
17// - created_at (date)
18//
19// Pre-call workflow:
20// 1. Build input_hash from current inputs
21// 2. Search Prediction_Cache where input_hash = [hash] and model_version = current_version
22// 3a. If found: use cached output (no TF Serving call)
23// 3b. If not found: call TF Serving, store result in Prediction_Cache
24
25// Certificate renewal check:
26// sudo certbot renew --dry-run
27// (Run this monthly to confirm automatic renewal is working)