How to Integrate Lovable with Wasabi

Log in to your Wasabi account at console.wasabisys.com. In the left sidebar, click 'Buckets' and then 'Create Bucket'. Enter a unique bucket name (bucket names must be globally unique across Wasabi), and select the region closest to your users — Wasabi offers US, EU, and AP regions with different endpoint URLs. The region determines the S3-compatible endpoint you will use; note it as you create the bucket (e.g., us-east-1 uses s3.wasabisys.com, eu-central-1 uses s3.eu-central-1.wasabisys.com). Set the bucket access to private. Leave versioning disabled unless your app specifically needs file version history — enabling it creates storage costs for each version retained. Click 'Create Bucket' to complete the setup. Next, create Access Keys for API authentication. In the Wasabi console, click your account name in the top right → 'Access Keys'. Click 'Create New Access Key'. Wasabi presents a Root User Access Key (has full account access — avoid using this) and recommends creating Sub-User Access Keys for applications. However, Wasabi's sub-user system is under their IAM section: go to IAM → Users → Create User, create a user named 'lovable-app', and under Policies, attach a policy that allows s3:GetObject, s3:PutObject, s3:DeleteObject, and s3:ListBucket on your specific bucket ARN. For faster setup: use the root access key during development (acceptable for initial testing). Switch to a scoped sub-user key before going to production. After creating the access key, Wasabi shows the Access Key ID and Secret Access Key once — copy both values immediately. The Secret Key is never shown again.

Open your Lovable project and navigate to the Cloud tab by clicking '+' next to the Preview. Click 'Secrets' to open the encrypted environment variable panel. Add the following secrets for Wasabi. Add WASABI_ACCESS_KEY_ID with your Wasabi Access Key ID. Add WASABI_SECRET_ACCESS_KEY with your Wasabi Secret Access Key. Add WASABI_BUCKET_NAME with the name of the bucket you created. Add WASABI_ENDPOINT with the full HTTPS endpoint URL for your bucket's region. Wasabi's endpoints follow this format: for us-east-1 use https://s3.wasabisys.com; for us-east-2 use https://s3.us-east-2.wasabisys.com; for us-west-1 use https://s3.us-west-1.wasabisys.com; for eu-central-1 use https://s3.eu-central-1.wasabisys.com; for ap-northeast-1 use https://s3.ap-northeast-1.wasabisys.com. Add WASABI_REGION with just the region identifier (e.g., us-east-1). For each secret: click the '+' button in the Secrets panel, type the exact key name, paste the value without any surrounding whitespace, and save. Key names are case-sensitive and must exactly match the names used in the Edge Function's Deno.env.get() calls. Never paste these credentials into the Lovable chat window. Credentials in chat history are visible and persisted — always use the Secrets panel. Lovable's security infrastructure — which includes SOC 2 Type II and ISO 27001 certifications — encrypts all secrets at rest and makes them accessible only to your Edge Functions.

The Wasabi Edge Function is structurally identical to a Backblaze B2 integration — both use the AWS SDK v3 S3Client pointed at a custom endpoint. The only configuration difference is the endpoint URL and credentials. This makes Wasabi adoption straightforward if you have seen an S3 or B2 integration. The key S3Client configuration for Wasabi requires: setting endpoint to your WASABI_ENDPOINT value, setting region to your WASABI_REGION, providing credentials from environment variables, and setting forcePathStyle: true (Wasabi, like B2, requires path-style URLs). Without forcePathStyle, the SDK constructs virtual-hosted-style URLs (bucket.s3.wasabisys.com) that Wasabi does not support. For pre-signed download URLs, Wasabi generates URLs that allow direct browser access to private objects without routing through the Edge Function. This is particularly important for large files: a 500 MB video should be delivered directly from Wasabi to the user's browser, not proxied through your Edge Function which has request size limits. The getSignedUrl function from @aws-sdk/s3-request-presigner works with Wasabi using the same S3Client configuration. Wasabi pre-signed URLs can have expiry times from 1 second to 7 days. For downloadable content, 1-24 hours is appropriate. For streaming media where users play videos in a browser player, set a longer expiry (24 hours) to avoid the stream failing mid-playback if the URL expires. Pre-signed URLs for Wasabi use the same format as AWS S3 pre-signed URLs — query parameters with X-Amz-Expires and signature values.

1import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'
2import {
3  S3Client,
4  PutObjectCommand,
5  ListObjectsV2Command,
6  DeleteObjectCommand,
7  GetObjectCommand,
8} from 'npm:@aws-sdk/client-s3'
9import { getSignedUrl } from 'npm:@aws-sdk/s3-request-presigner'
10
11const corsHeaders = {
12  'Access-Control-Allow-Origin': '*',
13  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
14  'Access-Control-Allow-Methods': 'POST, OPTIONS',
15}
16
17serve(async (req) => {
18  if (req.method === 'OPTIONS') {
19    return new Response('ok', { headers: corsHeaders })
20  }
21
22  const endpoint = Deno.env.get('WASABI_ENDPOINT')
23  const region = Deno.env.get('WASABI_REGION')
24  const accessKeyId = Deno.env.get('WASABI_ACCESS_KEY_ID')
25  const secretAccessKey = Deno.env.get('WASABI_SECRET_ACCESS_KEY')
26  const bucket = Deno.env.get('WASABI_BUCKET_NAME')
27
28  if (!endpoint || !region || !accessKeyId || !secretAccessKey || !bucket) {
29    return new Response(
30      JSON.stringify({ error: 'Missing Wasabi environment variables. Check Cloud Secrets.' }),
31      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
32    )
33  }
34
35  const s3 = new S3Client({
36    endpoint,
37    region,
38    credentials: { accessKeyId, secretAccessKey },
39    forcePathStyle: true,
40  })
41
42  try {
43    const body = await req.json()
44    const { action, key, prefix, content, contentType, expiresIn } = body
45
46    if (action === 'list') {
47      const result = await s3.send(new ListObjectsV2Command({
48        Bucket: bucket,
49        Prefix: prefix || '',
50        Delimiter: '/',
51      }))
52      return new Response(JSON.stringify({
53        files: result.Contents ?? [],
54        folders: result.CommonPrefixes ?? [],
55        count: result.KeyCount ?? 0,
56      }), { headers: { ...corsHeaders, 'Content-Type': 'application/json' } })
57
58    } else if (action === 'upload') {
59      if (!key || !content) throw new Error('key and content are required for upload')
60      const bytes = Uint8Array.from(atob(content), c => c.charCodeAt(0))
61      await s3.send(new PutObjectCommand({
62        Bucket: bucket,
63        Key: key,
64        Body: bytes,
65        ContentType: contentType || 'application/octet-stream',
66      }))
67      return new Response(JSON.stringify({ success: true, key }),
68        { headers: { ...corsHeaders, 'Content-Type': 'application/json' } })
69
70    } else if (action === 'get-download-url') {
71      if (!key) throw new Error('key is required')
72      const ttl = Number(expiresIn) || 3600
73      const url = await getSignedUrl(
74        s3,
75        new GetObjectCommand({ Bucket: bucket, Key: key }),
76        { expiresIn: ttl }
77      )
78      return new Response(JSON.stringify({ url, expiresIn: ttl }),
79        { headers: { ...corsHeaders, 'Content-Type': 'application/json' } })
80
81    } else if (action === 'delete') {
82      if (!key) throw new Error('key is required')
83      await s3.send(new DeleteObjectCommand({ Bucket: bucket, Key: key }))
84      return new Response(JSON.stringify({ success: true }),
85        { headers: { ...corsHeaders, 'Content-Type': 'application/json' } })
86    }
87
88    throw new Error(`Unknown action: ${action}`)
89
90  } catch (err) {
91    const message = err instanceof Error ? err.message : 'Unknown error'
92    return new Response(JSON.stringify({ error: message }),
93      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } })
94  }
95})

With the Edge Function deployed, build the React components for your specific Wasabi use case. The frontend calls supabase.functions.invoke('wasabi-storage', { body: { action, ...params } }) for all storage operations, processing responses and updating state accordingly. For media-heavy applications (the primary Wasabi use case), build components that handle large file uploads gracefully. Add client-side validation for file type and size before starting the upload. For files over 5 MB, show a progress indicator using XMLHttpRequest or the Fetch API with progress events — reading large files as base64 before sending can take several seconds and the user needs visual feedback. For video or audio content, the pre-signed download URL from Wasabi can be used directly in an HTML5 video or audio element src attribute. This streams the media directly from Wasabi to the user's browser with no intermediary. The Edge Function only generates the URL — the actual file data never passes through it. Set a generous pre-signed URL expiry (6-24 hours) for media to ensure playback sessions do not expire. For production file management, store all file metadata in Supabase: the Wasabi object key, original filename, file size, MIME type, upload timestamp, and uploader's user ID. This enables building a rich file library with Supabase queries — filtering by type, searching by name, sorting by date — without needing to call Wasabi's list API. The Wasabi pre-signed URL is only fetched when the user actually needs to access a file. For applications with user-generated content, add file key namespacing: prefix all keys with the user's Supabase user ID (uploads/{userId}/{filename}) to logically separate files by user. This does not enforce access control at the storage level (B2 and Wasabi bucket policies are less granular than S3 IAM), but combined with Supabase RLS on the metadata table, ensures users only see their own files in your app's UI.