Frequently asked questions

Yes, since 30 July 2026. pwestudio.online runs from one host on Oracle Cloud in the Melbourne region (ap-melbourne-1). It ran on AWS in Sydney until 17 September 2026 and moved on that day. Requests reach the host through Cloudflare, which carries the public certificate; a web server on the host receives them over TLS and passes them to the application. HTTP redirects to HTTPS and HSTS is set for one year. The application listens only on the host’s loopback interface and is reached through that edge.

In the Melbourne region (ap-melbourne-1), on the host itself: PostgreSQL 16 runs beside the application, and media files sit on the host’s own storage. The runtime connects with a restricted database role; the owner role is used only for schema migrations at start-up. No managed database, object-storage or mail service holds the live data. The one copy that leaves the host is the encrypted backup described in the next answer.

Yes to both. The database is backed up every night at about 03:15 Melbourne time; uploaded media and the rest of the host’s files are backed up on the first of each month. Each backup is encrypted on the host before it leaves, then stored off the host in Cloudflare’s object storage; Cloudflare does not hold the key. A restore was rehearsed on 17 September 2026: a database backup was fetched from that off-site copy, decrypted and restored into a separate database, and its tables and tenants matched production. Three limits are worth stating plainly. Media is copied monthly, not nightly, so an upload can be up to a month old before it has an off-site copy. The encrypted copy is kept in Cloudflare’s Oceania region, which is wider than Australia, so we do not describe that copy as held in Australia. And there is no automated alert if a backup run fails, so backup output is checked as an operator task rather than by monitoring.

Not yet. Uptime monitoring, backup-failure alerting, an on-call path and a contractual availability target are not in place. Health and version can be checked on demand, and a branded maintenance page is served if the application is briefly unavailable during an upgrade, but that is not the same as a monitored service with an SLA. Any availability target has to be written into a signed order form.

No, and this is now an open gap on a live service rather than a pre-launch to-do. Role separation, PBKDF2-HMAC-SHA256 password hashing with 600,000 iterations, HttpOnly session cookies, rate limiting on student access codes and audit logging are all in place. Multi-factor authentication for privileged accounts is not, and remains our highest-priority security item. Until it ships, keep privileged logins individual, use a password manager, and tell us immediately if you suspect an account is compromised.

Studio Admin is the owner’s website and brand workspace. CMS is the daily operations workspace for enquiries, students, rosters, attendance, credits, artwork and reports. They share identity and stable links, while responsibilities and permissions remain separate.

A family unlocks one student’s private area with the student name, the registered mobile number and a six-digit code issued by the studio. It shows that student’s credit balance, next class, attendance and portfolio, and nothing belonging to another student. Attempts are rate-limited and temporarily locked after repeated failures. Multi-child account aggregation is not part of v10.22.4.

Most operator actions open your own Mail or Messages application with prepared text, and you decide whether to send. PWE Studio also has a logged SMTP path for configured transactional events, but it sends externally only when the deployment supplies and operates its own sending account and domain. No managed sending domain or SMS provider transport is included by default.

No. Staff can record purchases, invoices, payments, refunds and credit adjustments, and every action is audited, but PWE Studio does not capture cards or move money. Automatic merchant/bank settlement reconciliation is deferred. The optional Xero add-on pushes recorded documents one way; it is not a payment processor. Do not upload payment-card numbers into any field.

We provide standard templates and a migration assessment. Arbitrary files usually need field mapping and may need paid clean-up. A production import only proceeds after an exceptions report, your written approval, a checkpoint, a rehearsal and a reconciliation.

There are two distinct exports. The weekly schedule contains active recurring classes, course details and location in the studio’s local time, and excludes student and guardian identities. The daily roster may contain student names because it is an operational attendance file; it is restricted to staff with data-export permission, is marked private before download and never contains guardian names.

In v10.22.4 one campus is one tenant and one subscription. This keeps student records, staff membership, schedules, brand, plan and — importantly — backup, export, deletion and incident scope independent per campus. A future organisation layer may aggregate isolated campus tenants for reporting without merging their operational data.

Studio pages remain under the platform domain; per-studio custom domains, Stripe, provider calendar APIs and SMS provider transport are deferred unless a signed order includes implementation and acceptance. Xero is different: it is a paid Beta add-on with OAuth, reviewed mappings, a Demo Company trial, a persistent queue and gated one-way push for issued invoices, credit notes and recorded payments. It never imports or applies edits from Xero, and pushing stays off until every gate passes.