App hosting & & WeWeb Servers & HIPAA

I’m working on a HIPAA-compliant SaaS application using WeWeb and considering self-hosting the exported code, potentially on GitHub-AWS Amplify.
Q: When I export the code and host it myself, does that automatically make my application “air-gapped,” meaning, except my backend, it won’t communicate with any external web servers including WeWeb servers like for authentication or other integrations?

I’ve come across docs discussing self-hosting weweb servers, but I’m not clear on whether this satisfies the requirements for the above.

Any insights would be appreciated!

Hi, it depends of which plugin and options you’re using.

If you’re toggling the “proxy through server” on a REST request it will be forwarded by our server for exemple.
If you’re using WeWeb Auth it will also ping our servers.
If you’re using Airtable we have a microservice to hide your API key so it use our servers.
If you’re using OpenAI its also a microservice to hide your API key and secure prompt.

Except a couple of exception, anything else is a direct connection between your frontend running in the browser and the connected API without WeWeb as a middleware.

If your application connect with xano, supabase, rest api or graphql you should be fine.

2 Likes

Thank you, Alexis. I appreciate your assistance, but I find myself a bit confused about certain aspects.

Let me please first clarify, the currently planned tech stack is as follows:

  • Hosting: AWS (EC2 for backend, Amplify for frontend).
  • Backend: Supabase and N8N for all backend and biz logic & including auth and databases queries.
  • APIs: REST and/or GraphQL from various sources like OpenAI, HuggingFace, AWS Lambda…etc
  • Frontend: Self-hosted using GitHub-AWS Amplify.

Given your response, I have a couple of questions:

  1. WeWeb Server Dependency: If we self-host the code, and given the above stack, will our application still need to communicate with WeWeb servers (if we host WeWeb Server on AWS)?

  2. If the answer to above Q is No, even with all the above, it still communcates with WeWeb servers, could you specify which components would still require communication with your servers?
    or If it’s more convenient, could you please direct me to the relevant documentation that outlines what’s included in the exported code and how it interacts with WeWeb servers post-export?

Thanks again!
Cheers

1 Like

I don’t see why you would need the weweb server if you’re using authenticated requests to supabase for relaying backend requests to your third-party providers (Which would be a good best practice).

In my experience best layout is:

  1. Weweb generating static files: JS/CSS/HTML combination for your vuejs app. This maximizes your ability to make use of CDNs and edge caching performance. These are then easy to copy over to your amplify, s3 bucket, or however you manage storage.
  2. Your backend layer managing authenticated requests, using a time-limited (usually 60m) access token stored in cookie or localstorage. Optionally have your front-end fetch new tokens from the backend so the user never has a gap in experience
  3. The backend is the only one with the keys for the third-party apis.

This stack means that you used weweb as your editor but not as your server. As a result, the code doesn’t “phone home” to weweb after you’ve exported it.

Two State Change members have now gone through this process with the help of our office hours. This stack works pretty well.

2 Likes

Except if you really need our secure page feature (not required to have a secure app as your data is already protected by your supabase as said by @raydeck) you don’t even need to self host our weweb server, you only need to export the code.

If you self host weweb server there is no more communication with WeWeb possible. Because you also lose the access to our microservices (but your stack doesn’t include any of them).

We dont have a detailed list of components relaying to WeWeb but we should!

I think we have : airtable, auth0, google, notion, openai, smartsuite, sql, stripe, weweb auth, soap* and rest api*

(*) only if you toggle the proxy option

3 Likes

Hi Alexis and Raydeck,

Thank you both for your invaluable insights; they have greatly clarified the server dependencies for my project.

From what I understand, utilizing Supabase for my backend and authentication and hosting the entire application on AWS will make my application independent of WeWeb servers post-export.

Furthermore, by establishing direct connections with REST and/or GraphQL APIs, it appears that no middleman involvement from WeWeb will be necessary.

Based on Alexis’s list, which includes:

  • Secure Page Feature - To be replaced by Supabase
  • WeWeb Auth - To be replaced by Supabase
  • Airtable Microservice - Rather connect directly via Supabase
  • OpenAI Microservice - Rather connect directly via Supabase
  • REST API with Proxy Option toggled on - To ensure this is not enabled

it seems that utilizing any of these components would require communication with WeWeb servers. Therefore, by avoiding these specific features, I should be able to eliminate the need for any such communication.

Please let me know if my understanding is inaccurate or if I have overlooked any items on the list.

Best regards,

2 Likes

Correct!

You summed it up well :slight_smile:

2 Likes

Awesome! Thank you :slight_smile:

1 Like

@zaj we are using Xano as a backend and are on their HIPAA plan. I’d recommend it as a quick way to get started fully HIPAA compliant without having to deal with self hosting Supabase, etc.

Could be an option for you if you prefer Xano over Supabase (although a bit more pricey)

1 Like

@Alexis can you confirm that the CSV extension doesn’t touch the WeWeb servers? Our use case is allowing our clients to export sensitive data from our app (this data needs to stay in the client). Thanks!

Do you mean google sheet ? Google sheet is a WeWeb microservice, it relate to “Google” in my list.

Referring to the CSV extension here. Just want to confirm that the data that is converted to a CSV doesn’t touch WeWeb’s server with the extension.

Nope, it doesn’t.

1 Like

@Alexis, if possible it’d be really helpful to have what and what not are used by the weweb server on a page on the Docs.
@Jack thank you for the info. We’ve considered xano and it’s very easy and cool. but the HIPPA pricing is not mentioned so that’s why we thought to explore supabase. Another note, on one of last Tuesdays Q&A - I was told that even for the ones that use weweb server, if you self-host the weweb server then you are all good :slight_smile:
Cheers,

1 Like

For sure! It’s on our to-do list :slight_smile:

1 Like