Hey @benallfree first of all thanks for providing us pockethost for testing pb in production. But I am facing an issue everytime, while doing realtime activities. I found this might be the reason that pockethost is going to idle mode?
If I am wrong can you suggest me how to make it work.
P.S: I am using react in client side.

Currently, no pocketbase queries run in SSR because the user is not authenticated. According to https://github.com/pocketbase/js-sdk#ssr-integration there may be a way to do this better so that we don't have to wrap stuff in <AuthStateguard>

Once we have paid tiers, do stripe integration for billing.

Can SES make a mail user and can we restrict sending from the pockethost.io domain only?

Right now, we don't verify email addresses. But we really should not let users start instances until their email is verified.

On the frontend, it should work like this:

• Create account
• Send out verification
• Post alert in UI if account is not verified, offer to resend verification

On the backend, it should work like this:

• Request comes in
• Look up owner
• Check verification status
• If owner is not verified, reject with a 403 Forbidden error

@brewhousedigital want to collab on this?

I want to know which instances are running and for how long, what PID, etc

Maybe each project gets 100 free minutes per month or something, then you have to upgrade.

Similar to #40, let's add a field in the profile or user record where we can disable accounts. This should probably wait until after PB v0.8 release, where user/profile refactoring has happened.

Following up on #7, the minimal dev setup I can imagine would be a two-step process, something like:

nano /etc/hosts  # add relevant entries for `pockethost.local`
docker-compose -f docker/docker-compose.dev.yaml up

I started a docker branch to capture some ideas. The docker/docker-compose.dev.yaml will assume a local domain of pockethost.local and will spin everything up in dev/watch mode.

If it is a completely new build, it will mount a /.secrets folder and save the generated pockhethost-central username and password there for future reference. Overridden by PB_USERNAME and PB_PASSWORD environment variables, if present.

After #21 and #43, it might be time to consider what a Free tier looks like.

This would be the ticket where we talk about Stripe integration and billing.

My first thoughts are that we should just focus on:

• Instance run time
• Total storage

Put some limits on those and if either one is exceeded, they can upgrade, maybe something like this:

Watch Pocket - Free Forever

• 100 minutes runtime per month
• 10MB storage

Front Pocket - $20:

• 1000 minutes of runtime per month
• 100MB storage

Back Pocket - $50 :

• 10,000 minutes of runtime per month
• 1GB storage

Cargo Pocket - Enterprise, let's talk

One thing to note is it might be possible to stay Free Forever by configuring an instance to use S3, if static files are the issue.

Historical deployments of #28 and #27 should not count against quotas.

pnpm is muuuch faster as a package management tool, supports workspaces, and uses symlinks for everything.

I haven't tested all our packages, sometimes react doesn't love it but not sure about svelte.

Wondering how others feel about this.

Inspired from pocketbase/pocketbase#862 (comment)

This isn't really hurting anything, just a little confusing for the user until a request comes in. Low priority. Wait for batch updates to hit the JS SDK.

Move PBScript to here & deprecate that old repo

Is there currently a way to delete / remove an instance?

If so, does that need to be added to the Instance Details page somewhere?

I think there is a way to create an S3 bucket and account limited to write permissions on just that bucket. When an instances is created, provision an S3 bucket and user and put those credentials into the pockdetbase instance.

Ability to restore mail and s3 credentials from PH admin

Notice the odd wrapping behavior

@brewhousedigital Want to take a look at this?

One hiccup in the backend dev experience is the need to manually create an admin user when spawning a fresh a pockethost-central db. Setting the first admin's credentials programmatically could alleviate this part of the process and help to make working on Pockethost a little closer to the simple experience that appeals to folks who choose to work with Pocketbase.

Here's a relevant discussion: pocketbase/pocketbase#793

With 0.4.0, we have the concept of platform names and versions within that platform. This is to group PocketBase versions by compatibility. For example, every version in the ermine group will run interchangeably. Just bug foxes. But the lollipop platform requires db upgrades and will not run ermine code or SDKs.

So, breaking changes means it's important to tell the users which version they're running.

The platform name is always the a literal platform name, but the version can either be a specific version or latest to make pockethost select the latest version in that platform group.

It would be great if all of this were explained better and more intuitive. I've stubbed out the basics, but I'm curious if others have feedback about how this concept should be presented.

@brewhousedigital want to take a shot at this?

Allow custom domains

Frontend:

• Add cname to instances
• cname must be blank or globally unique
• cname must be a valid domain name (https://www.regextester.com/106386)
• create instructions that cname must resolve to <uuid>.pockethost.io along with a button to test manually
• A cname_status flag: verifying, ssl, active, and failed
• A cname_reason field capturing the latest failure message

Daemon updates:

• For all instances with verifying status, do a cname check to make sure it links to the correct subdomain. If it doesn't, set to failed with a cname_reason
• CERTBOT - set to ssl and issue new SSL cert and update nginx & refresh, or set to failed with a reason
• Once cname and certbot are done, set status to active
• Periodically check (cname_checked_at) to re-verify that cname resolves properly - every 5 minutes? update status and reason if failure
• Periodically renew certbot (every 90 days) (certbot_renewed_at), updating status and reason if failure

Anything we can do about this @brewhousedigital ?

Ability to supply fly.io machine key and have instances deployed on dedicated resources

This task is to track and implement better SEO and Social Sharing capabilities using Open Graph.

Design

• Favicon
• Open Graph Poster
• Manifest Icons

Code / app.html

• Title Tag
• Meta Description
• manifest.json
• Open Graph Tags: url, type, title, description, image
• Twitter Meta Properties: card, domain, url, title, description, image

Code / Project

• Implement <svelte:head> on each page for better usability

This scope is limited to updating the core pockethost-central to run on 0.8. #52 will handle instance upgrades.

What about a logo that is just stacked boxes like this?

@brewhousedigital

This ticket discusses how best to integrate TS/JS functions.

Features:

• self-contained JS bundle
• version controlled
• ability to select active version from the pockethost admin
• ability to upload/select/rollback versions from the pockethost CLI
• extend pocketbase to look for pb_script/index.js as the entry point
• extend pocketbase with an admin-only API hook to reload the script
• bundle must export a version header

Example:

pockethost login test -u=xxx -p=xxx
pockethost functions deploy # reads version from bundle, abort if duplicate
pockethost functions rollback # goes back to previous version
pockethost functions select v4 # select specific version

Depends on:
#26

Another incremental step to #52, we can allow users to move between platforms which are not API compatible but that don't require any database migrations.

Platform boundaries are defined in two ways:

1. Breaking API changes
2. Database migration changes

This roughly corresponds to the minor number in semantic versioning, but not always. Any time there is more than a bug fix, we give it a new gopher name and make it into its own platform.

Backend changes:

• Write a function getNonMigratoryPlatformsAndVersionsList(platformId, version) that will return a list of compatible platforms and versions that don't require migrations.

Frontend changes:

• Use getNonMigratoryPlatformsAndVersionsList() to populate the version selection dropdown.
• If the user selects a DIFFERENT platform, alert them (danger zone) that this choice certainly means they are moving to an incompatible version of PocketBase with incompatible API changes and that their client SDK will need to be updated accordingly.

@brewhousedigital let's hold on this one until we have an actual situation where this occurs. As of now, all platforms require db migrations.

Placing on hold in favor of #53

@brewhousedigital This is an all-frontend idea, no backend coding needed.

Check out how Stripe does their API samples https://stripe.com/docs/api

I think PocketBase supports REST, Dart, and JavaScript as the three client SDK's. It would be cool to have a widget like Stripe does that swaps code samples based on preferred SDK. And the SDK selection would be sticky in a cookie.

Hello! Wanted to try out Pockethost, so I created an account and created a new app. For the last few hours it's been stuck on this view:

The domain is incalculable-death.pockethost.io

Do we need that cookie compliance pop up thing that everyone is doing?

@brewhousedigital

• Choose instance name
• Init project in JS or TS
• Create static site
• Create Ping cloud func
• Start a repo of boilerplate projects - JS, TS, Python, Dart, other?

Hello!

Trying to run pockethost locally (interested in contributing!) but hitting a wall getting going. I'm not 100% familiar with Docker, so there's a good chance this error has a quick fix, thought I'd ask here.

When I run docker compose up, everything runs smooth but pockethost-central fails to initiate correctly:

pbproxy  | pockethost-central had error Error: spawn /mount/pocketbase/bin/pocketbase EACCES

This leads to endless polling of the 'central' pb instance further along:

pbproxy  | Trying to connect to instance http://127.0.0.1:8090 
pbproxy  | Could not connect to http://127.0.0.1:8090

Tried some suggestions I could find online re: permissions & docker compose but, like I said, sorta out of my depth & interested if you can point me in the right direction.

Thanks!

@brewhousedigital suggested in #35 name-name-number rather than just name-name.

Since every instance gets a unique ID, I think the backend should always answer on that subdomain:

ctg834u9gc.pockethost.io

Then I think it's still valuable for users to be allowed to pick a globally-unique name if they want to:

foo.pockethost.io

That, along with #25 support, will create a nice tidy solution.

If they want to rename an instance, they can do that because metrics are linked to the uuid and not the subdomain name.

Proposed frontend changes:

• Name: /[A-Za-z-]/ max 50 chars
• Name must be globally unique
• Name can be changed at any time
• Name CANNOT match any instance uuid

Proposed daemon changes:

• Recognize both uuids and names when resolving instance requests

Static assert deployment

Features:

• fast file diffing
• rsync?
• version controlled
• ability to select active version from the pockethost admin
• ability to upload/select/rollback versions from the pockethost CLI
• beta subdomain and version preview subdomains
• must have VERSION file in static root
• Auto-assigned subdomain expires in 7 days

Example:

pockethost login test -u=xxx -p=xxx
pockethost static deploy # rsync's current version or fails on duplicate
pockethost static rollback # goes back to previous version
pockethost static select v4 # select specific version
pockethost static deploy --subdomain=mytest # Deploy to `mytest` subdomain AND auto-assigned subdomain

open https://298g2j.test.pockethos.io  # auto-assigned version
open https://mytest.test.pockethost.io # manually-assigned version

Depends on:
#26 

Backups are something we can offer.

• Should this be an S3 thing?
• How does this relate to #23?
• Ideally users should not need to configure their own S3 creds
• How does this relate to #27 #28

I started work on #36 but once I pulled from master, my navigation is blank now except for the non-auth links. I cleared cache but no good. Was there anything I needed to do locally to get things working with the new authcheck?

As an incremental step to #52, we can most easily move between versions in the same platform.

@brewhousedigital We now have two pocketbase platforms, Ermine (0.7.x) and Lollipop (0.8.x) which multiple versions in each.

Here's what I propose:

Frontend mods:

• From instance details page, present dropdown listing all available versions plus one entry named latest
• When the user changes the selection, write the new value to their instance in the version field
• If the instance is running, warn them that the change will take effect immediately, causing the instance to be shut down and restarted, and that all open connections will therefore be dropped.
• For clarity: if they pick a specific version, write that value. if they pick latest, write the { version: 'latest' } to the db

When you're done with that, I'll do these backend mods:

• When an instance is running, monitor the record for changes. If the version changes, kill the instance so it will start up again using the new version

See pocketbase/pocketbase#880 for discussion.

• What versions are interchangeable as far as API and migrations?
• How to manage one-time upgrades/migrations?
• Data backup strategy?
• How to roll back if something goes wrong?
• DB snapshots and restore points?

@brewhousedigital mind taking a peek at this?

Open to discussion, after #21

I like how PocketBase.io has an emphasized button leading to their docs. I’d like a similar one for our discussions area. Basically encouraging people to engage in discussion.

@brewhousedigital

Thoughts on whether this is needed? So far nobody is asking anything.

@brewhousedigital

• Webmail client per instance

When doing a fresh login, the dashboard does not load apps and the navbar doesn't change.

@brewhousedigital I'm taking a peek at this unless you have immediate ideas.

Create an admin user [email protected] in each PocketBase instance so that PH can perform admin functions on the PB instance.

Example uses:

• Making protected API calls such as reload cloud function script
• Adjust admin settings such as mail and s3 credentials