Passerelle: connecting software without exposing it
Passerelle receives a message at a secure address, transforms it as you wish, then sends it on to one or more services: Slack, CRM, support desk, spreadsheet, file server or a custom API.
Status: version 0.22.0, built and validated in-house. The service is not yet open to the public, so no access link is offered.
Context and problem solved
A company’s tools do not always talk to each other: a negative review should alert the team, a contact request should create a CRM record, an export should reach a partner. Each link needs development, a server to watch and secrets to protect, and it can then break silently.
Passerelle takes over this plumbing: secure reception, transformation, delivery with automatic retries, history and alerts. It targets marketing, support, product and technical teams in small and medium businesses who want to automate without maintaining a server, and integrators who manage several clients (one organisation per client).
How it works
- A flow = a secure entry address + transformation steps + destinations. The entry is protected by a token (two at most, rotated without interruption), an optional signature and a list of allowed addresses.
- Steps: filter (drop a message), fields (add or change), mapping (reformat) and free-form Python script run in a sandbox. JSON, XML, SOAP, form and CSV formats are handled on input and output.
- Ready-made connectors: Slack, Discord, Microsoft Teams, Google Chat, WhatsApp, email, Airtable, HubSpot, Intercom, Zendesk, Pipedrive, Google Sheets, SFTP and a generic HTTP request, plus custom connectors with draft, three previous versions and rollback.
- Reliability: automatic retries spaced up to about 12 hours, manual retry, every error explained in plain language, dry-run, confirmed live test and test environments for the services that offer one.
- Alerts, monitoring and oversight: sending condition per destination, site monitoring (port, interpreted HTTP response, certificate), a supervision screen sorted by severity and reports exportable as CSV.
- Usage-based billing: credit packs rather than a subscription; filters and fields are free and a failure costs nothing.
Technical choices and architecture
- Stack: the same foundation as Boussole (Python API with FastAPI, PostgreSQL, Celery tasks and Redis, Next.js 16 interface). The transformation engine (paths, templates, conditions, signatures) relies on the standard library only, and templates never execute code.
- Running other people’s code: a customer’s script runs in a child process with an empty environment, strict time and memory limits, analysed code and a closed list of importable modules. In production it is handed to a dedicated service: a container with no network, read-only and unprivileged. A script that escaped Python would land in an empty container.
- Isolation and secrets: each organisation is an isolated space; secrets (API keys, passwords) are encrypted and never displayed again; outgoing calls are locked to the service’s domain and protected against server-side request forgery.
- Minimal data: a message’s content is erased after processing (kept encrypted for seven days only on failure, to allow a retry); the history, without content, lasts 30 days.
- Container-based deployment: Docker Compose with a reverse proxy; operational metrics (Prometheus format) with no customer data, and an alert to the operator when processing falls behind.
- Tests: unit tests, integration tests on real PostgreSQL and SFTP servers, interface tests and a browser journey.
Difficulties and lessons learned
- Allowing free-form Python safely: security rests on several successive layers rather than a single protection, with a clear working assumption: the script is foreign code.
- Throughput: on a development machine, with a three-step flow including one script, 100 messages and a single worker, processing throughput went from 4.5 to 14.7 messages per second and the median delay from 10.2 s to 1.6 s. Two fixes were enough: process the queue until it is empty, and load the script’s modules on demand.
- Reading XML safely: the standard library is vulnerable to external entities and expansion bombs; parsing goes through a small dedicated library that rejects them.
- Changing billing model: the subscription was replaced by credits; the related data migration is deliberately not reversible.
- Spoofable IP addresses: forwarding headers are only accepted from the proxy network, otherwise a flow’s allowed-address list could be bypassed.
- Accepted limits: no visual editor for a custom connector’s fields (JSON input), reports limited to 30 days, “ping” implemented as a TCP port test.
Honest status
Today, the 0.10 to 0.17 roadmap is complete and releases have continued up to 0.22.0 (supervision, report filters and exports, operational metrics, alerts, XML and CSV formats, connections and scheduled API reads).
What remains before opening: fill in third-party service accounts (transactional email, payment), have the privacy text reviewed and set the credit pack amounts, currently provisional. Quality checks run locally; no opening date is announced.
What this shows about my work
- Designing an integration platform that handles third-party data and secrets, with security as the starting point.
- Measuring before optimising, and documenting the gains obtained.
- Reusing a proven foundation (Boussole’s) while checking that the parts copied between projects stay consistent.
- Writing documents for each audience: sales presentation, user guide, functional documentation, release notes, operations.
To connect your own software with a custom solution, see also workflow automation.
Software to connect?
Describe your tools and the flow you want and I will tell you how I can help.
