Lagniappe is designed to be installed as your own App Engine application, using your own Google Cloud project and Redis Cloud database. The most important security boundary is simple: the browser is a client, and the server is the authority.

A Lagniappe install does not depend on a centralized Lagniappe SaaS control plane. Your records, files, cache data, and provider accounts stay with the services you configure for your instance.

Lagniappe uses server-rendered pages with JavaScript widgets layered on top. That shape is useful for security because private records are not shipped to the browser for the frontend to sort out later. The access decision is made once, on the server, before content is sent. Since the browser is never handed data it is not allowed to see, there is no client-side permission logic that can be bypassed or drift out of sync with the server.

• Permission checks happen before rendering. Protected routes verify the current user and requested action before returning content.
• Search and filters respect access. Restricted items are left out of rendered pages, search results, filter results, and direct route responses.
• Mutations go through server routes. Forms, uploads, task changes, permissions, and settings changes use backend routes protected by CSRF and permission checks.
• Cached pages still have server fingerprints. ETag values and service-worker invalidation headers help clients refresh stale private views after changes.

Lagniappe has one configured primary Owner and may have additional Administrators. Administrators can operate the application, including ordinary Site Settings, user and group management, ingress, content, and content exports. AI entitlement remains a separate per-user choice.

The Owner alone changes the Administrator roster, changes or deletes an Administrator account, protects the canonical Owner account, and views or downloads installation configuration. That configuration can contain Redis passwords, API keys, SMTP credentials, and recovery material, so the Maintenance / Configuration control is not rendered for additional Administrators and its server routes reject them as well.

During a delegated installation, one exact saved installer email may use Google sign-in to create a temporary application Administrator only until the primary Owner’s first successful login. The email is never advertised on the public login page. Owner login closes automatic creation permanently; an already-created installer remains an Administrator until the Owner removes it. The later handoff deploy clears the saved bootstrap value before removing the installer’s managed cloud access.

In the default production shape, Lagniappe runs on App Engine standard environment. App Engine is a managed Google Cloud runtime: Google runs the underlying infrastructure, starts and stops application instances, and isolates apps in the standard-environment sandbox. App Engine terminates HTTPS for app traffic, and the default Lagniappe configuration sends HSTS so browsers remember to use HTTPS for future requests. MDN’s HSTS reference explains the browser side of that header.

Google Cloud provides default encryption at rest for customer content and protects traffic moving within its infrastructure. Those provider controls reduce the infrastructure you have to operate yourself. The installer configures the access the application needs; protect the Google accounts that administer the project and review that administrator access when people or responsibilities change.

Lagniappe uses Redis for search indexes, filters, cache entries, rate limits, active viewer state, and collaboration/sync state. Redis should be treated as operational application data: it is not the long-term source of truth, but it can still contain meaningful names, keys, search text, session-adjacent state, and workflow context.

Redis Cloud is a hosted Redis service, but security is still shared responsibility. Redis operates the Redis Cloud software and platform, the selected cloud provider handles the underlying infrastructure, and the operator controls the plan, region, database security settings, credentials, connectivity, and what data is stored. Reference: Redis Cloud shared responsibility.

Think of Redis TLS as HTTPS for the server-to-server connection between Lagniappe and Redis Cloud. The Redis password is still required to authenticate the application. TLS adds another layer around that password-authenticated connection: it encrypts the traffic in transit and verifies that Lagniappe is talking to the expected Redis Cloud server. The password controls who may connect; TLS protects the connection carrying that password and the application data.

• At rest: Redis Cloud supports encryption at rest for deployments, including databases hosted on Google Cloud.
• In transit: Redis Cloud TLS encrypts application-to-database traffic when enabled. Paid Essentials/Flex and Pro plans can enable database TLS, but Free Essentials plans cannot. Lagniappe supports verified server TLS through its guided security setup.
• Network exposure: Redis Cloud can use CIDR allow lists on supported plans, block public endpoints on Pro plans, and connect privately to Google Cloud through Private Service Connect. CIDR allow-list automation may be added later if there is demand, but it requires a stable App Engine outbound IP path through Google Cloud networking.
• Current app boundary: Lagniappe connects to Redis from the server side on App Engine. That keeps Redis credentials out of the browser, but App Engine alone does not automatically make a Redis public endpoint private or encrypted in transit.

Redis references: encryption at rest, TLS, public endpoint blocking, CIDR allow lists, and Private Service Connect.

• Error reporting: Disabled unless the operator enables it during setup. The operator can send privacy-reduced reports to the maintainer or, after declining that destination, supply a DSN for their own Sentry project. When enabled, Lagniappe disables backend Sentry default PII collection, but may still attach diagnostic request or error context such as URL, endpoint, headers, form fields, JSON payloads, or file metadata. Read the maintainer error-reporting privacy notice before enabling the default destination.
• Analytics: Optional Administrator-facing analytics can record page path, title, view type, referrer, navigation type, and user identifiers for authenticated visits.
• AI generation observability: Setup explicitly offers the default-off AI_OBSERVABILITY choice. When enabled, it samples every text generation into an Administrator-only summary dataset. Records exclude prompts, generated text, tool arguments/results, messages, file content, and application identifiers; activity-driven cleanup deletes up to 500 records older than 30 days after each new summary, so stale records can remain when generation is inactive. SDK-internal retries are not visible.
• AI and OCR: Vertex AI and Document AI receive the prompts, documents, images, or extracted context needed for the feature the user invokes.
• Browser storage: The service worker caches app responses for responsiveness and offline behavior. The app can ask clients to clear cached Lagniappe responses after permission or content changes.

• Use strong Google account protection and keep at least one recovery path for the Cloud project.
• Give Lagniappe owner and administrative permissions only to people who need them, and review user and group access when responsibilities change.
• Protect local settings files and recovery downloads; do not commit secrets to a public repository.
• Review public pages, public files, public permissions, and group memberships from a non-owner account.
• Decide whether optional analytics, AI generation observability, AI/OCR, and error reporting match your privacy expectations before enabling them.
• For Redis, choose the strongest connectivity controls your plan supports and treat cache/search data as sensitive operational data.