The canonical redeploy cycle. CLAUDE.md has the longer first-time setup flow (also walked through in PostgreSQL Local Deployment); this page is the routine version that lives in muscle memory.
Every time you want to see your local code change running. Every time.
Tomcat's webapps directory is at tomcat/tomcat-11/webapps/. Tomcat
auto-deploys WARs dropped into that directory, but it doesn't always
pick up wiring changes from a hot reload (filter chains, listener
order). A full stop-swap-start cycle is the safe baseline, and
bin/redeploy.sh is that cycle in one command: it stops Tomcat, waits
for port 8080 to release, rotates catalina.out, replaces the exploded
webapps/ROOT with the fresh WAR, applies any pending database
migrations and starts Tomcat. It does not build; run the Maven step first.
bin/deploy-local.sh is the heavier alternative — it also validates
secrets, renders any config files that do not exist yet, upgrades the
JDBC driver and seeds the admin account. Use it for first-time setup and
after pulling a branch that changed Tomcat, the JDBC driver version or
the config templates; otherwise the routine cycle above is faster.
The frontmatter steps are the canonical sequence. The readiness
check at the end (step 3) is the difference between "Tomcat is up"
and "the structural index has finished bootstrap" — both matter for
agent-grade endpoints.
The frontmatter pitfalls capture the recurring traps. The costly one
is believing a template edit has taken effect: the files rendered into
tomcat/tomcat-11 (wikantik-custom.properties, ROOT.xml,
log4j2.xml, setenv.sh) are written once and never overwritten, so
a change to the template under wikantik-war/src/main/config/tomcat/
silently does nothing for an existing install. Edit the deployed file
instead (it survives redeploys), or delete it and re-run
bin/deploy-local.sh.
Cluster Hub: Agent Cookbook (agent-cookbook)