נבנה עם Lovable

כבר באוויר ב Lovable? שם זה ממשיך לעבוד. הכתובת עוברת רק כשמחברים דומיין.

יש בפרויקט התחברות משתמשים, תשלומים, או מידע שנשמר בין ביקורים?

להעתיק את ההנחיה ולהדביק אצל המנוע שבנה את האתר

You are packaging a working web application for deployment on Handsome Hosting.
Produce a single .tar.gz archive of the project, laid out exactly as follows.
Work autonomously from start to finish: these rules decide everything this task
needs, including permission to edit config and fix build errors. Do not stop to
ask questions. If something is genuinely ambiguous, pick the option that changes
the app least and state the choice in your final summary.

1) Create a file named handsome.json at the archive root:
{
  "manifestVersion": 2,
  "project": { "name": "<app name>", "type": "webapp" },
  "needs": { "runtime": "node", "database": <"mysql" if the app uses MySQL/MariaDB, else null> },
  "secrets": [ { "name": "<ENV_VAR_NAME>", "label": "<short human label>", "generate": <true if the value is just random bytes the platform should create, else omit> } ]
}
List under "secrets" only the environment variables the app cannot start or
sign in without (session secrets, encryption keys, credentials the
app reads only from the environment). If the app has its own in-app settings
screen for API keys or preferences, leave those out: the owner enters them
inside the app after launch. When unsure, list fewer and do not stop to ask:
every value can also be added after launch from the project settings page.
Mark "generate": true on any secret whose value is nothing but random bytes
(session signing secrets, encryption keys): the platform creates those itself
and the owner is never asked for them.
Names only, UPPER_SNAKE_CASE, never the values. Do not list PORT, HOST,
HOSTNAME, NODE_ENV, DATABASE_URL, APP_BASE_URL or any DB_* name: the platform
provides those (APP_BASE_URL is the public https URL of the deployed instance).
If the app needs its public URL under another name (NEXTAUTH_URL, APP_URL,
PUBLIC_URL and similar), do not list that name as a secret: assign it from
APP_BASE_URL in code at startup. The URL exists only after deploy, so the
owner cannot type it in.
The server has no local mail system: never send mail through localhost:25,
sendmail, or a bundled MTA. If the app sends email (sign-in links,
notifications, receipts), send over SMTP driven entirely by environment
variables: SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS, and MAIL_FROM for the
sender address; use implicit TLS when SMTP_PORT is 465, STARTTLS otherwise.
List those five under "secrets" (never "generate": true) so the owner can
fill them in at checkout. When SMTP_HOST is empty, keep the app fully
usable: disable sending, show a clear in-app notice that email is not
configured yet, and never crash and never fall back to localhost.

2) If the app is Next.js: set output: "standalone" in next.config, run the
production build yourself, then copy .next/static into .next/standalone/.next/static
and public/ into .next/standalone/public. Also copy any directory the server
reads from disk at runtime (prompts, templates, data files) into .next/standalone/
at the same relative path: the standalone tracer does not bundle runtime file
reads, and the deployed server runs with .next/standalone as its working
directory. Package these at the archive root:
package.json, package-lock.json, next.config.*, .env.example, handsome.json,
and the whole .next/standalone directory.

3) If the app is any other Node.js server: make sure "npm start" launches it,
listening on process.env.PORT and binding process.env.HOST. Package the project
root including package.json and package-lock.json (a lockfile is required).

4) Never include real secret values. Exclude every .env file except .env.example.
Exclude node_modules and .git.

5) Run the production build and fix every error before packaging. A project
whose build fails cannot be hosted. If the build needs environment values,
build with placeholder values in a local .env and do not package that file.

6) Name the archive after the app (for example reports-maker.tar.gz). It must
be at most 25 MB compressed and 64 MB unpacked; if it is larger, exclude build
caches, sourcemaps and other files the server does not need at runtime.

Include a basic accessibility layer so the site is usable with the keyboard and by assistive tech: at minimum visible keyboard focus, a skip-to-content link, adjustable text size, a high-contrast option, and correct ARIA landmarks. A baseline layer, not a substitute for an accessibility audit or statement.

איך מוציאים את הקובץ

לייצא את הפרויקט מ Lovable, או להוריד אותו מ GitHub עם "Download ZIP".
להעלות את הקובץ כאן לבדיקה.

בחירת קובץ

יש בפרויקט התחברות משתמשים, תשלומים, או מידע שנשמר בין ביקורים?

איך מוציאים את הקובץ

הרשמה